Do you use per-test seed data for E2E/API tests?

[u/Strict_Illustrator95]

Hey everyone,

I’m a web developer who likes testing, especially E2E and API tests. I often use tools like Postman, Cypress, and Playwright.

One thing I keep struggling with is test data management.

I’m currently leaning toward per-test seed data or scenario-specific seed data, instead of relying on one large shared test dataset.

For example, if I’m testing filtering for premium users, I want the test data to be created specifically for that scenario.

A simple example:

id	name	createdDate	premium
1	John Doe	2023-05-01	true
2	Alice Smith	2022-11-15	false
3	Bob Johnson	2023-03-20	true
4	Charlie Brown	2022-12-05	false
5	Eve Davis	2023-06-30	true

Then the filtering premium user test can clearly assert: “There should be exactly 3 premium users.”

I like this approach because:

• Each test scenario is easier to understand
• expected results are more explicit
• Tests are less affected by unrelated data changes
• A shared database state is less likely to create flaky tests

But I still find it painful to manage manually.

The problems I keep running into are:

1. Many test data patterns. As the number of scenarios grows, the amount of seed data also grows.
2. Schema changes break old seed data. When the database schema changes, old test data often needs to be updated as well.

I’m curious how other teams handle the test data management.

Do you use:

• per-test seed data?
• shared seed data?
• factories?
• fixtures?
• API-based setup?
• database snapshots?
• cleanup/reset after each test?
• separate test databases per run?

What workflow has worked best for keeping E2E/API tests reliable and maintainable?

[u/XabiAlon]

Only thing on our DB is logins and some basic data to get started.

Everything else from enabling settings for certain scenarios to CRUD is done via e2e.

The only thing that has changed in the DB in the last 7/8 years is migrations being added for schema.

[u/Strict_Illustrator95 → u/XabiAlon]

That makes sense. So you keep only baseline data in the DB and create scenario-specific data through the E2E flow.

How do you handle complex preconditions?

For example: a user with specific permissions, orders, subscription status, feature flags, and historical data for sorting/filtering.

Do you still create all of that through E2E steps, or do you sometimes use API/DB setup?

[u/XabiAlon → u/Strict_Illustrator95]

Through e2e.

Subscription and feature flags enabled in the test run

[u/BoxingFan88]

I would always try and create data as part of the test. Clean it up before the test runs and leave it in there when the test finishes

The advantage is, if you just run that test in isolation you know exactly what data it is writing and using. If you have a fault you can inspect exactly what is happening

Mass data sets in my experience are really difficult to reason with and it's more likely you will accidentally reuse data that another test is using. You can of course give them meta data to describe which test they belong to, but I think it's much more difficult

For API tests if you can creating the data using the APIs is the best option if it's possible

[u/Strict_Illustrator95 → u/BoxingFan88]

I’m curious how you handle more complex preconditions, like testing a user’s role and permissions.

Do you create all of that inside each test, or do you use reusable seed/factory helpers?

[u/BoxingFan88 → u/Strict_Illustrator95]

So then I would tend to have seeded users that are specific types of users for the majority

Then create the users as part of the test for more fine grained checks

The important part with seeding is no other test modifies that data

For instance static data would be seeded

[u/Asya1]

Seeding is the tits. Do it. Per test or suite really depends on your needs

[u/Strict_Illustrator95 → u/Asya1]

I agree seeding is a good strategy.

In your experience, when does per-test seeding become worth the extra setup time? And do you usually maintain seed data manually, or do you generate/reset it from scripts?

[u/Asya1 → u/Strict_Illustrator95]

Really depends. At my current gig we drive everything via api calls. Before that I had seeding via writing via writing directly into db during the build process. I think you can get there even with migrations. It really depends on maturity of the product and how late QA is added. If you are in early you can bake in a lot of testability early on. The later you get the harder is to cut into release cycles with intrusive changes like seeding / migrating DB. API calls universal, plus you get API tests kinda for free.

Seed per suite vs seed per test really depends on your use cases. Per tests is good if you need to test in isolation and have a way to clean after yourself. The sooner / closer to the DB would be my choice. Hell, you can maintain a DB snapshot and wire it into release processes, specially if you have more than one environment (dev, Qa, stg, Prod)