Synthetic Address Test Data: Designing Reproducible Fixtures

Fixed and random fixtures serve different jobs

Fixed fixtures suit snapshots, contracts, and migrations. Random generation expands combinations, but without a seed it creates failures nobody can replay.

Keep a small reviewed regression set and a generator that accepts seed, country, and scenario. Promote useful failures into fixed fixtures.

Recognizable without breaking the format

Use reserved domains such as example.com, add dataPurpose and fixtureId, and log fixtureId instead of a full address. Keep the postal shape realistic when testing a parser.

Never copy a customer and replace only the name. Other fields can still identify a person or send notifications.

{
  "fixtureId": "ca-boundary-003",
  "dataPurpose": "synthetic-test",
  "seed": 7319,
  "countryCode": "CA",
  "email": "qa-7319@example.com"
}

Random does not mean inconsistent

Define invariants: country format agrees, regional fields come from one tuple, postcodes remain text, and optional lines stay empty rather than N/A. Property tests can check these over many seeds.

An invalid fixture may break one invariant, but should declare expectedError so nobody treats it as normal data.

• Every seed is replayable
• Normal regional tuples stay consistent
• Invalid fixtures break one named rule
• Output records the reference-data version

Prevent production side effects

Test email, SMS, printing, fulfilment, and payment integrations through sandboxes or outbound blocks. Writing Test in an address does not prevent a real logistics call.

CI should verify environment and credential types and reject synthetic-test records entering production queues.

Turn failures into regression assets

Keep the minimal failing record, seed, data version, and assertion. Deduplicate periodically, but do not regenerate stable fixtures merely to make them look fresh.

Give each fixed fixture an owner, scenario, expected outcome, creation reason, and review date. A large JSON file that does not explain the behavior it protects quickly becomes a pile nobody trusts and nobody dares delete. During review, identify duplicate coverage and rules the product no longer applies.

Do not take UI snapshots from unrestricted random output. Use an explicit fixed record for snapshots and let random tests assert properties and invariants. That division prevents meaningless snapshot churn whenever a generated street changes while still preserving broad exploratory coverage.

Treat a reference-data upgrade like a dependency change. Run the old seed set against the new snapshot, review intentional differences, and retain both versions long enough to explain why a previously reproducible record changed.

Track coverage by scenario, not by the raw number of generated rows. Ten thousand ordinary addresses do not replace one deliberate fixture for a missing unit, leading-zero postcode, overlong building name, or unsupported region. A compact coverage matrix lets reviewers see which rule each fixture exercises and where the generator still has blind spots.

• Assign an owner and protected behavior
• Review duplicate and obsolete cases
• Use fixed fixtures for snapshots and random fixtures for properties
• Version reference-data upgrades explicitly