Seed data

Preloaded users, orders, and other records that give a test environment the same useful starting point on every run.

“put some records in the test database first”“my test environment is empty”“fake users and orders for testing”“load sample data before the tests”“starter records for CI”“why is my local app completely blank”“seed date”“pre-fill the test database”

What it is

Seed data is a known set of records loaded before tests run so the environment is not empty. A browser suite might start with an admin, three customers, and orders in each status; an integration suite might seed the lookup rows its foreign keys require. The point is a useful, repeatable baseline, not a realistic copy of production.

Reach for it when many tests need the same broad world. Keep the seed deterministic, version it with the schema, and let individual tests add the one-off records that make their case distinctive. Prisma's db seed hook and Faker with a fixed random seed are common ways to build that baseline.

Gotcha: shared seed data quietly creates order dependence. One test edits the seeded admin, another expects the original email, and the suite fails only in parallel. Reset mutations between tests or give each worker its own database, and never depend on auto-generated IDs remaining the same unless the seed explicitly controls them.

Ask AI for it

Create deterministic test seed data with Prisma's db seed hook and @faker-js/faker. Call faker.seed(42), upsert stable lookup rows by natural key, then create an admin, three customers, and orders covering every documented status. Keep production data out, make a second run produce no duplicates, expose a reset command for CI, and give each parallel Playwright worker its own database name.

You might have meant

test fixtureintegration testend to end testtest isolation setup and teardownseed data