Skip to content
Multigrid

Test Fixture Generator From Examples

Turn real records into committable test fixtures in Python, TypeScript, JSON or JSONL, with every identifier replaced by a stable fake.

Values replaced
16

Across 2 example(s) and 20 leaf values. The structure was compared before and after: same keys, same types, same array lengths.

Examples in the fixture
2
Leaf values
20
Leaves changed
11
Untouched
9 (45%)
Output characters
1,073
What was replaced:
  • Email addresses: 2 replaced
  • API-key-shaped strings: 2 replaced
  • UUIDs: 2 replaced
  • IPv4 addresses: 2 replaced
  • 12–19 digit runs (card-shaped): 2 replaced
  • Phone-shaped numbers: 6 replaced
Where it was replaced:
  • [0].id
  • [0].customer.email
  • [0].card_last_seen
  • [0].source_ip
  • [0].api_key
  • [0].note
  • [1].id
  • [1].customer.email
  • [1].card_last_seen
  • [1].source_ip
  • [1].api_key
What this assumes: the replacement is deterministic and one-way. The same real value always becomes the same fake one under the same salt, so a customer who appears in three records still appears in three records and a foreign key still joins — and there is no table anywhere that maps back, because a reversible anonymiser is a database of the thing you were trying not to keep. The detectors are patterns, not understanding: a name in a free-text field, a postcode, an internal account number in a format nobody documented — none of those are found. Read the output before you commit it. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.

The best test data is real data, and real data is exactly what must not end up in a repository. So most fixtures get invented instead, and invented fixtures share a flaw: they contain the cases the author thought of. The empty string, the emoji in the name field, the amount that is a string in one record and a number in the next — those come from production, and they are the cases that break code.

Why the same fake value every time

A redactor that used a random value per occurrence would destroy the thing that makes the example useful. If one customer id appears in an order, a refund and an audit line, all three must still point at each other afterwards or you no longer have a scenario, you have three unrelated rows. Hashing the original value with your salt gives that for free — and it means running this page again next month on a fresh export produces fixtures that still match the ones already committed.

What it does not find

Everything it does not have a pattern for. A person's name in a free-text note is not detectable by shape; nor is a street address, a medical detail, or the internal reference number that means something to your support team. This is a first pass that removes the mechanical 80% — the emails, the keys, the ids, the card-shaped digits — and the list of exactly which values it changed is printed so you can see the shape of what it caught and infer what it missed. The last read is yours.

Keep the salt out of the repository

The mapping is not reversible without the original data, but it is reproducible: anyone with the same salt and the same real record can confirm the two go together. That is a small leak and a real one if your records are sensitive enough. Put the salt somewhere other than next to the fixtures it generated.

The reasoning behind this

Related tools

Test Fixture Generator From Examples · Multigrid