Using Data in Tests - The Right Way

Systems without data are like cats without something to drop on the floor. Boring and a lot safer. We use data in our tests all the time. We feed the system, we get results. Some of them are even expected. But we can't use just any data. We need to understand what to use where. In this video, I use a simple Create User API to show what happens when you hard-code an email that needs to be unique. First run - no problem. Second run - boom. That's the wrong kind of data. In this video I cover: → Hard-coded unique fields — breaks on second run → Random values — works, but debugging becomes detective work → Data factories — more control, better documentation, easier reproduction Next time you write a test, look at the data you're sending. Know what's unique, what's safe, and what's going to bite you on rerun. 🔗 REGISTER FOR THE WEBINAR — "Modern API Testing: Fighting Flakiness" June 3rd, 3PM CET / 9AM EDT. Free. Seven suspects behind flaky tests. Live examples. And a tool I built to surface hidden assumptions. https://us02web.zoom.us/webinar/register/7817677801362/WN_Wo6ezTHfR3Smru0VRXxsSg 📚 The API Testing Masterclass: The Strategist is coming later in 2026. Not like any API testing course out there. 👉 Join the waitlist → https://testingil.com/mc-api-testing-strategist Connect with TestinGil: 🌐 Website: https://www.testingil.com/ 💼 LinkedIn: https://www.linkedin.com/in/gilzilberfeld/ 🦋 BlueSky: https://bsky.app/profile/gilzilberfeld.bsky.social If you enjoyed this video, please: ✅ Like the video ✅ Subscribe to the channel ✅ Share it with someone who hard-codes emails in tests — they know who they are #apitesting #SoftwareTesting #TestAutomation #QualityEngineering #StateManagement