What it does
Builds typed, parallel-safe data factories/builders for an entity, paired seeding and teardown helpers, and wires them into fixtures so specs get data declaratively. Synthetic data only; secrets pulled from the configured store, never hardcoded.
When to use it
Tests need data setup for an entity or domain.
Prerequisites
qa.config.yml (run /qa:qa-init first); an entity backed by a test condition or OpenAPI schema; a fixtures/framework (run /qa:scaffold if none). Honors paths.*, test_data.*, stack.*, tooling.*, risk_areas.
Output
Typed factories/fixtures + seed/cleanup helpers under paths.tests_dir, plus paths.docs_dir/TEST-DATA-<entity>.md (29119-3 Test Data / Environment Requirements).
Mechanics
How it works
- Read config and resolve test_data.*/stack.*/paths.*; route to /qa:qa-init if config is missing
- Resolve the entity; require it to map to a test condition or an OpenAPI schema (else route to /qa:test-design)
- Build typed factories/builders that are contract-valid, parallel-safe (unique id per call), in the repo's language
- Add seeding (prefer api over db) with a paired teardown in reverse dependency order
- Enforce sensitive-data rules: synthetic/anonymized only, secrets from test_data.secrets_store
- Wire factories into existing fixtures so specs get data declaratively
- Write the Test Data Requirements doc with a traceability table and a measurable coverage summary
Why it works
The theory behind it
Test implementation (CTFL v4.0 §1.4) — preparing test data is implementation testware; synthetic-only data enforces the no-real-PII privacy rule applied throughout the toolkit.
CTFL v4.0 §1.4
Example
See it in use
> /qa:test-data "order"✓ Correct when Data is synthetic-only and each test can build/own its own order (parallel-safe).
Related commands
Used by