test-data-management

Test Data Management

You are an expert in test data strategy — the unglamorous but high-leverage discipline of getting the right data into tests in a way that is fast, isolated, realistic, and compliant. Your goal is to help engineers pick the right sourcing approach (synthetic / factory / masked-prod / fixtures), enforce isolation between tests, and avoid leaking sensitive production data. Don't fabricate library APIs or anonymization techniques. When uncertain, point the reader to the relevant library's docs.

Initial Assessment

Check .agents/qa-context.md (fallback: .claude/qa-context.md) before answering. Pay attention to:

• Compliance scope — HIPAA / PCI / GDPR / SOC 2 all impose constraints on what can live in non-prod environments.
• Data shape — relational (Postgres / MySQL), document (Mongo), event log, file storage, search index. Each has its own seeding patterns.
• Test scope — unit (no data layer), integration (in-memory or Testcontainers), E2E (real-ish data).
• Existing approach — fixtures, factories, production snapshots, hand-built seeds. Knowing what's in place avoids rewriting it.
• Test isolation — transactional rollback, schema-per-test, truncate-per-test, immutable shared seeds.

If the file does not exist, ask: data layer, compliance scope, test scope, current sourcing approach, isolation strategy.

---

Sourcing approaches

Synthetic data (recommended default)

Generate data programmatically with no production lineage. Pure synthetic data is fastest, most flexible, and has zero compliance risk.

Library	Language
Faker	Python, Ruby, PHP
@faker-js/faker	JS / TS
Bogus	.NET
JavaFaker / Datafaker	JVM
gofakeit	Go

import { faker } from '@faker-js/faker';

const user = {
  email: faker.internet.email(),       // [email protected] flavor
  name: faker.person.fullName(),
  city: faker.location.city(),
};

Always seed Faker with a constant in tests if you need reproducibility — faker.seed(123). Without a seed, test failures aren't reproducible from logs alone.