Anonymize test data without breaking the test

Editorial review: 2026-11-04 · Sources and scope below

The customer database replaced the address with customer-1@example.invalid. The order service used customer-87@example.invalid for the same person. The application joins these systems by email. Each database is internally consistent. The combined workflow is broken.

This is a constructed engineering example. It follows one requirement through preparation and validation. Customer 1 must see orders 101 and 102, worth 30,000 cents together. Original email addresses and personal notes are unnecessary for that check.

The relationship missing from the schema

A declared foreign key is visible in the database model. A connection between services may exist only in application code or a JSON field. Tonic explicitly describes undeclared relationships and consistency across columns and generations. For our example, the same customer needs the same replacement in both systems. Check that property for the chosen fields and runs. Stable replacement values also create linkability that needs consideration with real data.

Tonic relationship guide

What does anonymization mean here?

Masking changes or conceals values. Whether people remain identifiable depends on the resulting dataset and its context. Pseudonymized records may remain attributable through additional information. Replacing an email alone does not establish anonymity. Order histories, rare combinations and free text can retain identifying information.

BfDI guidance on test data

Choose the transformation around the test

Approach	Result	Check
Static masking	Transformed values stored in a test copy	Remaining originals in targets, exports and staging
Dynamic masking	Values displayed according to query or permissions	Roles that can still access original values
Transformation during transfer	Changed fields on the path to the target	Staging and logs along that path
Rule-based generation	Records produced from specified rules	Relationships, constraints and expected behavior

A transformed source subset can support investigation of an existing failure. Generated records can add deliberate edge cases. The required output determines which combination is useful.

ISO overview of masking

Define the small dataset before transforming it

All values in this example are invented.

Field	Before	After	Reason
Customer ID	1	1	Preserves the fixture relationship
Name	Demo Person A	Test customer 1	Provides a display value
Email	original-a@example.invalid	customer-1@example.invalid	Supplies a unique replacement
Internal note	Invented personal note	NULL	Unnecessary for this test
Status	paid	paid	Determines inclusion in the result
Amount in cents	10000	10000	Contributes to the expected total

For real records, retained IDs may link back to other systems. Exact amounts and histories also require review. If IDs change, their mapping must remain consistent across the required relationships.

Prepare and check the result

Write the expected business query first. Select customers, orders and required dependent records. Inspect sensitive content in structured fields, JSON, notes and logs. Apply explicit transformations while checking uniqueness, null handling, field lengths and relationships. Repeat acceptance checks after the final import.

For this fixture, require two customers, three orders, no orphan orders, the exact replacement email pattern and empty notes. Customer 1 must have two paid orders totaling 30,000 cents. Review remaining identifiability separately for real data.

Compare the documented workflow

These descriptions come from vendor sources reviewed on 4 November 2026. They are not results of a product benchmark.

Vendor	Documented workflow	Question for the same PoC
DATAMIMIC	Source metadata, reviewed field mappings, an editable de-identification model and execution	Does the reviewed model preserve the customer's mapping across both targets?
Delphix	Masking and virtual data delivery with refresh and rewind	Do related data states and masking rules remain consistent after refresh?
GenRocket	Synthetic generation and transformation of existing data, including In-Place Masking	Does the available release support the required database and transformation?
Tonic Structural	Consistent transformations, linked generators and virtual foreign keys	Are relationships held only in application code included?

GenRocket's January 2026 announcement listed Oracle and SQL Server for the initial release and PostgreSQL as planned. That announcement alone does not establish current PostgreSQL availability.

DATAMIMIC workflow · Delphix TDM · GenRocket announcement · Tonic relationships

The next failure is missing from the production copy

Once the order list works, the team adds a duplicate-order test. Two messages carry the same order ID. The application should create one order and handle the second message according to an agreed rule. Define that result before producing the data.

A larger production copy only contains this case if it already occurred there. A specified scenario can instead be generated deliberately. The vendor articles describe this choice, but the actual scenario still needs its own acceptance check.

DATAMIMIC discussion of masking and synthetic data · GenRocket approach

Repeat the checks after refresh

The next export must still support the regression test. Check mappings, required rows and the business query again. Refresh and rewind are explicit parts of Delphix's delivery workflow. For any candidate, ask how the team returns to a known, checked state after a change.

Our example ends with a precise requirement. Customer 1 sees orders 101 and 102 totaling 30,000 cents. The original email and note are removed. The duplicate-order scenario has a separate expected result. Give the same requirements to each candidate.

Delphix delivery workflow

How we assess sources