Summary
Add a test-data-management skill that provides structured guidance on creating, organising, and maintaining test data — fixtures, factories, builders, and seed sets — across Python, TypeScript, and Scala test suites.
Motivation
Three existing skills — test-unit-write, test-unit-standards, and test-unit-review — redirect test data questions to a test-data-management skill that does not exist yet. Users asking "how should I structure fixtures for complex objects?", "factory vs fixture — which should I use?", or "my test data is leaking between tests" are not served by any current skill.
Proposed scope
The skill should cover:
- Strategy selection — when to use inline literals, fixtures, factories, builders, or seed files; decision table by data complexity and reuse surface
- Implementation guidance — language-specific recipes:
- Python:
pytest fixtures (scope, autouse, parametrize), factory_boy, polyfactory, Faker
- TypeScript/Jest:
beforeEach setup, object-mother pattern, faker-js, fishery
- Scala/MUnit:
FunSuite fixture methods, ScalaCheck generators, custom builders
- Isolation rules — no shared mutable test data; scope fixtures to the narrowest lifecycle needed; reset strategies (truncation, transactions, in-memory)
- Anti-patterns — global mutable singletons, production database seeds in unit tests, hardcoded IDs that collide, over-specified data hiding intent
- Parametrization — table-driven tests, property-based generation, boundary value sets
- Relation to
test-unit-write — the writer skill delegates data-setup decisions here; this skill must be compatible with that handoff
Acceptance criteria
Related skills
test-unit-write (upstream delegator — data setup)test-unit-standards (peer — fixture reuse and isolation rules)test-unit-review (peer — flags test data violations)test-mocking-patterns (sibling new skill)
Summary
Add a
test-data-managementskill that provides structured guidance on creating, organising, and maintaining test data — fixtures, factories, builders, and seed sets — across Python, TypeScript, and Scala test suites.Motivation
Three existing skills —
test-unit-write,test-unit-standards, andtest-unit-review— redirect test data questions to atest-data-managementskill that does not exist yet. Users asking "how should I structure fixtures for complex objects?", "factory vs fixture — which should I use?", or "my test data is leaking between tests" are not served by any current skill.Proposed scope
The skill should cover:
pytestfixtures (scope, autouse, parametrize),factory_boy,polyfactory,FakerbeforeEachsetup, object-mother pattern,faker-js,fisheryFunSuitefixture methods,ScalaCheckgenerators, custom builderstest-unit-write— the writer skill delegates data-setup decisions here; this skill must be compatible with that handoffAcceptance criteria
SKILL.mdwith frontmatter (name,description,license,compatibility)references/for at least Python and TypeScriptevals/evals.jsonwith ≥ 5 trigger and ≥ 3 body evalsNOT:pointers updated intest-unit-write,test-unit-standards, andtest-unit-reviewto reference this skill by nameRelated skills
test-unit-write(upstream delegator — data setup)test-unit-standards(peer — fixture reuse and isolation rules)test-unit-review(peer — flags test data violations)test-mocking-patterns(sibling new skill)