Test Data Management
Purpose
Give tests the data they need without the flakiness and risk that bad test data causes: factory-generated, per-test-owned, deterministic, and never sourced from production — so tests are isolated, repeatable, and safe.
When to Use
- For any test needing data: integration, API, E2E, component with data.
- Not for reference/seed data the app requires (
../../database/seed-data) — though tests reuse its factories.
Inputs
- Schema + data layer (factories speak its language —
../../database/prisma-relational/etc.).
- Personas needed for authorization tests (users, roles, tenants —
../../backend/backend-authorization).
- Isolation strategy from the environment (
test-environment-management).
Discovery Questions
- What entities/personas do tests need (anonymous, user A, user B, admin, other-tenant)?
- How is data isolated per test (transaction rollback, truncate, unique-tenant-per-test)?
- Does any test path risk touching or copying production data (it must not)?
Responsibilities
- Build factories (not static fixtures): parameterized builders producing valid entities with sensible defaults and per-test overrides; composable for relationships. Factories survive schema change; static dumps rot.
- Provide deterministic personas for authorization coverage: A/B users, roles, and separate tenants — the fixtures that make cross-user/cross-tenant denial tests possible (
api-integration-testing, integration-testing).
- Enforce per-test ownership + isolation: each test creates what it needs and rolls back/cleans up; no shared mutable dataset that couples tests and causes order-dependent flakes (
flaky-test-audit).
- Keep data deterministic: seeded randomness where variety is needed, fixed values where assertions depend on them; controlled clock for time-sensitive data.
- Never use real production data or PII in tests — generated fake data only; production dumps in test/dev are a breach vector (
../../security/privacy-review, ../../database/database-security).
Required Workflow
- Inventory needed entities + personas (incl. authorization actors).
- Build/extend factories with defaults + overrides + relationships.
- Wire per-test isolation with the environment strategy.
- Provide the persona set for authorization tests.
- Verify no production-data path; verify repeat-run determinism.
Decision Rules
- Factories over fixtures — the default; static fixtures only for genuinely fixed reference values.
- Each test owns its data; shared mutable state is the top cause of flaky, order-dependent suites.
- Determinism where assertions depend on values; randomness (seeded) where variety exposes bugs.
- Zero real PII in tests — non-negotiable.
Rules
- No production data or real PII in any test.
- Tests don't depend on each other's data or order.
- Factories stay typed against the current schema.
Anti-Patterns
- Giant shared seed dataset every test reads and some mutate.
- Anonymized-ish production dumps as test data.
- Hardcoded IDs assuming a pre-existing row.
- Non-deterministic data breaking assertions intermittently.
- No distinct personas → authorization denial can't be tested.
Validation Checklist
Definition of Done
Factory-driven, per-test-owned, deterministic test data with the personas needed for authorization coverage, isolated to prevent order dependence, and provably free of production data or PII.
Related Skills
../../database/seed-data, integration-testing, api-integration-testing, test-environment-management, flaky-test-audit, ../../backend/backend-authorization, ../../security/privacy-review, ../../database/database-security.
Related Knowledge
../../../knowledge/ (personas, entity shapes).
Related References
../../../references/testing/ (factory patterns, when populated).
Context Loading Guidance
- Requires: schema/data layer, persona needs, isolation strategy.
- Does not require: production data (forbidden), full app source.
- May load:
test-environment-management, ../../database/seed-data.
- Stop when: factories + personas + isolation are in place and PII-free.
Token Efficiency Guidance
The entity/persona inventory + factory list is the artifact; build per entity, don't dump example rows en masse.
1---2name: test-data-management3description: Use to plan test data — factories over fixtures, per-test isolation, deterministic personas (users, roles, tenants) for authorization tests, and strict separation from production data. No real PII in tests; data is owned per test, not shared and mutated.4---56# Test Data Management78## Purpose910Give tests the data they need without the flakiness and risk that bad test data causes: factory-generated, per-test-owned, deterministic, and never sourced from production — so tests are isolated, repeatable, and safe.1112## When to Use1314- For any test needing data: integration, API, E2E, component with data.15- **Not** for reference/seed data the app requires (`../../database/seed-data`) — though tests reuse its factories.1617## Inputs1819- Schema + data layer (factories speak its language — `../../database/prisma-relational`/etc.).20- Personas needed for authorization tests (users, roles, tenants — `../../backend/backend-authorization`).21- Isolation strategy from the environment (`test-environment-management`).2223## Discovery Questions2425- What entities/personas do tests need (anonymous, user A, user B, admin, other-tenant)?26- How is data isolated per test (transaction rollback, truncate, unique-tenant-per-test)?27- Does any test path risk touching or copying production data (it must not)?2829## Responsibilities3031- Build **factories** (not static fixtures): parameterized builders producing valid entities with sensible defaults and per-test overrides; composable for relationships. Factories survive schema change; static dumps rot.32- Provide **deterministic personas** for authorization coverage: A/B users, roles, and separate tenants — the fixtures that make cross-user/cross-tenant denial tests possible (`api-integration-testing`, `integration-testing`).33- Enforce **per-test ownership + isolation**: each test creates what it needs and rolls back/cleans up; no shared mutable dataset that couples tests and causes order-dependent flakes (`flaky-test-audit`).34- Keep data **deterministic**: seeded randomness where variety is needed, fixed values where assertions depend on them; controlled clock for time-sensitive data.35- **Never use real production data or PII** in tests — generated fake data only; production dumps in test/dev are a breach vector (`../../security/privacy-review`, `../../database/database-security`).3637## Required Workflow38391. Inventory needed entities + personas (incl. authorization actors).402. Build/extend factories with defaults + overrides + relationships.413. Wire per-test isolation with the environment strategy.424. Provide the persona set for authorization tests.435. Verify no production-data path; verify repeat-run determinism.4445## Decision Rules4647- Factories over fixtures — the default; static fixtures only for genuinely fixed reference values.48- Each test owns its data; shared mutable state is the top cause of flaky, order-dependent suites.49- Determinism where assertions depend on values; randomness (seeded) where variety exposes bugs.50- Zero real PII in tests — non-negotiable.5152## Rules5354- No production data or real PII in any test.55- Tests don't depend on each other's data or order.56- Factories stay typed against the current schema.5758## Anti-Patterns5960- Giant shared seed dataset every test reads and some mutate.61- Anonymized-ish production dumps as test data.62- Hardcoded IDs assuming a pre-existing row.63- Non-deterministic data breaking assertions intermittently.64- No distinct personas → authorization denial can't be tested.6566## Validation Checklist6768- [ ] Factories with defaults/overrides/relationships.69- [ ] Deterministic personas (A/B/admin/other-tenant) available.70- [ ] Per-test ownership + isolation wired.71- [ ] Determinism verified (repeat runs stable).72- [ ] No production data / PII anywhere.7374## Definition of Done7576Factory-driven, per-test-owned, deterministic test data with the personas needed for authorization coverage, isolated to prevent order dependence, and provably free of production data or PII.7778## Related Skills7980`../../database/seed-data`, `integration-testing`, `api-integration-testing`, `test-environment-management`, `flaky-test-audit`, `../../backend/backend-authorization`, `../../security/privacy-review`, `../../database/database-security`.8182## Related Knowledge8384`../../../knowledge/` (personas, entity shapes).8586## Related References8788`../../../references/testing/` (factory patterns, when populated).8990## Context Loading Guidance9192- **Requires:** schema/data layer, persona needs, isolation strategy.93- **Does not require:** production data (forbidden), full app source.94- **May load:** `test-environment-management`, `../../database/seed-data`.95- **Stop when:** factories + personas + isolation are in place and PII-free.9697## Token Efficiency Guidance9899The entity/persona inventory + factory list is the artifact; build per entity, don't dump example rows en masse.
ahtishamshahzad