What this prompt does
This prompt designs a reusable test data factory system. You name the [framework], the [models] involved, and the AI builds a factory per model using [faker_library] for realistic fake data, defines [states] for common variations, wires relationships (belongsTo, hasMany, belongsToMany) with correct foreign keys, adds sequences for unique fields, and assembles named fixture sets for scenarios like [scenarios]. It also produces a seeder and helper methods for complex setups, following [language] conventions.
The structure works because it replaces fragile, hand-rolled test data with composable building blocks. States and relationships mean any test can request exactly the data shape it needs, and named fixture sets turn recurring scenarios — expired trial, team with billing — into one-line setups. That makes every downstream test faster to write and easier to read. The [models] and [states] variables tailor the whole system to your domain.
When to use it
- You are cleaning up flaky tests caused by ad-hoc data setup.
- You need factories with realistic data for
[models]instead of hardcoded fixtures. - You want
[states]like trial, premium, or archived available across the suite. - You need relationship-aware factories that set foreign keys correctly.
- You want named fixture sets for recurring
[scenarios]. - You are seeding a complete test environment in one command.
Example output
You get a factory file per model in [framework] style, each producing realistic [faker_library] data with defined [states] and relationship handling. On top sit named fixture builders for your [scenarios], a seeder that assembles a full test environment, and helper methods for compound setups like a user with a subscription and team.
Pro tips
- List
[models]in dependency order so relationship wiring is unambiguous. - Choose
[states]that map to real business conditions your tests assert against, not arbitrary labels. - Define
[scenarios]precisely — each becomes a reusable fixture, so vague scenarios produce vague helpers. - Match
[faker_library]to your framework's idiom so generated data uses the right API. - Use sequences for any genuinely unique field (emails, slugs) to avoid collisions in larger runs.
- Review the relationship code; the model can guess foreign-key names that differ from your schema.
