Test Data Management Strategy

## ROLE
You are a test infrastructure engineer who specializes in test data management for complex applications. You've solved the hardest test data problems: interdependent data, production-like volumes, and test isolation in parallel execution.

## OBJECTIVE
Design a test data management strategy for [APPLICATION] with [DATABASE TYPE: PostgreSQL / MongoDB / MySQL] that supports [NUMBER] parallel test runs while maintaining test isolation and realistic data.

## TASK

### Data Strategy Overview
- Test data categories: static reference data, dynamic test-specific data, production-like datasets
- Isolation levels: per-test isolation, per-suite isolation, shared read-only data
- Data lifecycle: creation → usage → verification → cleanup
- Ownership: each test owns its data, no shared mutable state between tests
- Determinism: same test always uses the same data structure (though values may vary)

### Factory Pattern
- Factory design: functions that create domain objects with sensible defaults
- Override pattern: customize any field while keeping defaults for the rest
- Traits: named variations (e.g., user.admin(), user.deactivated(), user.withSubscription())
- Sequences: auto-incrementing values for unique fields (email_1@test.com, email_2@test.com)
- Associations: factories that create related objects (order creates user + products)
- Lazy evaluation: only create data when accessed (reduce unnecessary setup)
- Language-specific: FactoryBot (Ruby), factory_boy (Python), Fishery (TypeScript), Instancio (Java)

### Database Seeding
- Seed types: minimal (required reference data), standard (realistic dataset), full (production-like volume)
- Seed scripts: idempotent, version-controlled, environment-aware
- Reference data: currencies, countries, categories, roles — loaded once, read-only
- Migration compatibility: seeds updated when schema changes
- Performance: parallel seeding for large datasets
- Synthetic data generation: Faker-based realistic data generation

### Test Isolation Strategies
- Transaction rollback: wrap each test in a transaction, rollback after assertion
- Database reset: truncate and re-seed between test suites
- Schema isolation: separate database schemas per parallel runner
- Container isolation: fresh database container per test suite
- Tenant isolation: multi-tenant applications use unique tenants per test
- Trade-offs: speed vs isolation — choose based on test type

### Production-Like Data
- Anonymized production snapshots: copy production data with PII removed
- Anonymization rules: consistent hashing for referential integrity
- Volume testing: large datasets for performance-sensitive tests
- Edge case injection: add known edge cases to production-like data
- Refresh cadence: weekly or monthly production snapshot updates
- Compliance: ensure anonymization meets GDPR and data protection requirements

### API-Based Test Data
- Setup via API: create test data through application APIs (validates API too)
- GraphQL mutations: create complex object graphs in single requests
- Admin endpoints: dedicated test data management APIs (staging/test only)
- External service mocking: WireMock, MockServer for third-party data
- Stateful mocks: mocks that maintain state across multiple requests

### Cleanup Strategies
- After-each cleanup: delete test-specific data after each test
- After-suite cleanup: batch cleanup after test suite completion
- Garbage collection: background process for orphaned test data
- TTL-based: test data auto-expires after configurable time
- Identifier patterns: prefix test data IDs for easy identification and bulk deletion
- Verification: ensure cleanup doesn't delete non-test data

### Debugging and Troubleshooting
- Data inspection: tools to view test data state during debugging
- Snapshot preservation: option to keep data from failed tests for investigation
- Data lineage: trace which factory/seed created which data
- Logging: log data creation and cleanup for audit trail
- Conflict detection: identify tests that accidentally share or corrupt data

## OUTPUT FORMAT
Test data management design document with factory implementations, seeding scripts, isolation strategy, cleanup procedures, and debugging tools.

## CONSTRAINTS
- Data creation must be fast: factory creation under 10ms per object
- Parallel test runs must not interfere with each other
- Test data must not leak into production databases
- Strategy must work for both unit and integration test levels
- Include migration strategy for existing tests without proper data management