Test data factory

A helper that builds a fresh, valid test object from defaults, while each test overrides only the details that matter.

helper that makes fake users for testswhy does every test need twenty fields filled inmake test data with defaultsstop copy pasting test objectsfresh test object every timetest data factroyoverride just one field in test datafunction that builds sample records

See it

Live demo coming soon

What it is

A test data factory is a function or builder that returns a fresh, valid test object from sensible defaults while letting each test override the few fields it cares about. Instead of repeating a twenty-field User literal, a test calls makeUser({ role: 'admin' }). Factory Bot in Ruby and Fishery in TypeScript package this pattern.

Reach for a factory when model constructors grow, valid objects require several related fields, or copied fixtures keep breaking after schema changes. Keep defaults boring and valid, create nested records through other small factories, and make unusual values visible at the call site.

Gotcha: random factories make failures hard to reproduce, and clever factories hide why a record is valid. If @faker-js/faker supplies data, seed it and print the seed on failure. Always return a new object, avoid implicit database writes in a plain build function, and do not let one giant factory accumulate every scenario in the product.

Ask AI for it

Create typed TypeScript factories for User and Order using Fishery and @faker-js/faker. Give every required field a valid default, accept Partial overrides, return fresh nested objects on every build, and seed Faker with a fixed value in the Vitest setup file. Keep build separate from Postgres persistence, add explicit createUser and createOrder helpers for database writes, and refactor the tests so each case overrides only the fields its assertion depends on.

You might have meant

test fixtureseed data testing qatest isolation setup and teardownparameterized test table driven testunit test