Test identity data is a made-up person, written down in full. It is a name, an address, a date of birth, a government identification number, a telephone number and a handful of smaller fields, assembled so that software can be exercised on a record that looks ordinary without describing anybody who exists.
This guide explains where such records come from, which situations genuinely call for them, why production data is a bad substitute even when it is available, and what a generator on this site does — and does not — guarantee about the result.
What test identity data actually is
Strip away the jargon and a test identity record is just a coherent set of answers to the questions a form asks. Somebody has a given name and a family name, lives at an address inside a particular region, was born on a particular day, and holds whatever identification number that region issues. The record is coherent in the sense that the answers agree with each other.
What makes it test data rather than real data is provenance. Nothing in it was copied from a human being, and nothing in it belongs to a human being. It has the shape of a person so that a system can process it, and no referent outside the test.
That distinction matters more than it sounds. A record can be perfectly formatted and completely fabricated at the same time, and both properties are the point.
When does a team actually need records like these?
Five situations come up over and over. They look different but share one requirement: the software must be given plausible input while the output goes somewhere harmless.
| Situation | What goes wrong without generated records |
|---|---|
| Functional testing of forms | Validation rules for length, character set and required fields cannot be exercised at all |
| Demonstrations and screenshots | Placeholder text such as a single repeated letter makes the product look unfinished |
| Bulk seeding and load rehearsal | A database needs thousands of rows before anyone can measure performance honestly |
| Automated test fixtures | Assertions drift when the same test produces a slightly different record on every run |
| Migration rehearsals | A move between environments cannot be rehearsed on data that does not resemble the real shape |
None of these is improved by real people’s details, and several of them become harder when real details are mixed in. That is not a moral point; it is a practical one about what a test needs in order to be useful.
Why production data is the wrong substitute
The instinct to copy a slice of production into a lower environment is understandable. Real data has the right distribution, the right edge cases and the right messiness. It is also the most expensive kind of data to lose, and lower environments are exactly where security controls are weakest.
Two failures follow. The first is regulatory: a name together with a date of birth, an identification number or a contact detail is personal data, and moving it into a development environment is a new use of it that nobody consented to. The second is operational: the copy persists in backups, in query logs, in screenshots attached to bug reports and in the laptops of everyone who ever restored it. The organisation now has many more copies of the same sensitive records than it had before, in places nobody is watching.
The privacy rules for test data article goes through this in more depth, including why stripping names out of a copied table is not the same as making the table anonymous. The short version is that the safest test record is one that was never anybody’s.
What a generated record contains
On this site, the identity and test data generator builds the whole set at once rather than one field at a time. A record typically carries a personal section with names, birth date and gender; an address section with street, city, administrative division and postal code; contact details; and the administrative identifiers that the chosen country actually issues.
Two properties are worth understanding before you lean on the output. The first is internal consistency: the address belongs to the country you selected, the telephone number carries that country’s calling prefix, and where a country’s national identifier has a published check-digit rule, the generated number satisfies it. The second is reproducibility. Output is driven by an identity key, and the same key with the same country produces exactly the same record — which is what makes a generated record usable inside an automated test rather than merely inside a manual one.
Every record produced this way is synthetic and exists for testing alone; it must not be used to impersonate a real person, and it is not a credential that any authority has issued or would accept.
Do generated records need to look real?
They need to look ordinary, which is a weaker requirement. A record that looks exotic is a record that tests the wrong thing: if every generated family name is a single syllable or every street name is a placeholder phrase, the layout is never stressed and the validation never fires. Generated data earns its keep when it lands in the same shape as the real input the system will eventually receive, including the awkward shapes — long names, names with diacritics, addresses written without spaces, numbers carrying a leading zero.
Looking ordinary is not the same as being usable. Holding a correctly shaped identification number does not mean it belongs to anybody, and it will not satisfy a check that consults the issuing authority, because there is no record behind it to consult.
Why the same field pairs keep failing consistency checks
Teams that hand-build test records run into the same defects repeatedly, and they are almost always relationship defects rather than value defects. The street is plausible, the city is plausible, the postal code is plausible — and the three belong to different countries.
The reason is that a hand-written record is assembled field by field, and each field is judged in isolation by whoever typed it. Randomness does the same thing at speed: independent draws produce impossible pairs far more often than intuition suggests. A generator avoids it by deciding the country and the administrative division first and deriving everything downstream from those two choices, which is why the field consistency question is really a question about generation order.
For developers: what an identity record is made of
Model the record as fields with dependencies, not as a flat row of independent columns. Name and gender, birth date and age, country and telephone prefix, division and postal code, country and identifier format: each pair has one member that constrains the other, and a schema that hides that relationship will let inconsistent rows in.
Two field-level habits prevent most damage. Never derive age from a stored integer when the birth date is also stored — keep the date and compute the age, or the two will disagree the moment a year passes. And where a country issues no particular identifier, treat the field as legitimately absent rather than filling it with a plausible-looking string, because an empty field and a wrong field fail in very different ways.
For fixtures, prefer a fixed record over a fresh random one whenever the assertion is about behaviour rather than about input variety. A test that asserts on a specific response needs to know what the input was. Reserve random generation for the tests that are hunting for unknown edge cases, and once such a test finds something, freeze that record as a fixture so the regression is locked down. Whatever the fixture holds, the note in the file should say it plainly: these records are synthetic, they are for software testing only, and they are not to be used as anyone’s identity.
Next steps
Pick one form in your product and fill it with a generated record instead of the placeholder text that is probably sitting there. Then take the same identity key and generate again — if the second record differs from the first, you are looking at a tool that cannot support automated assertions, and the vitest fixtures approach describes what to ask for instead.