There are three ways to get a fake record, and they are not interchangeable. A library runs inside your process and hands you values. A hosted generator returns whole records over a network call. An online tool gives a human a page with a button on it. Choosing badly costs you either reproducibility or time, and the cost usually shows up months later, in a test suite nobody trusts any more.
This guide compares the three on the properties that actually decide the choice, and describes the split most teams end up with.
Three ways to get a fake record
The library is a dependency in your project that produces values on demand. Faker is the familiar example in the JavaScript ecosystem and the one most teams reach for first, though the pattern is common to every language with a test-data package.
The hosted generator moves the data model to a service. Instead of assembling per-field values you ask for a record for a country and receive a complete one: a person, an address, a postal code, a phone number and, where the country publishes an algorithm, an identity number consistent with it.
The online tool is a page that generates a record when somebody clicks. It needs no install and no credentials, and the record is usually read by a person rather than asserted on by a program.
What a data-faking library is good at
The strengths of a library are real. It runs offline, so unit tests need no network. It is fast enough to call inside a test loop. It offers typed generators for names, phone numbers, addresses and company names across a long list of locales, and it slots into factories and fixtures so that building a valid domain object takes a few lines.
Factories make the glue explicit, which is the most useful thing a library can offer. A factory calls the faker in a fixed order, so at least the object’s own shape is consistent from run to run.
Where does a library stop being enough?
A library generates fields, so consistency across a record becomes your problem. The city, the postal code and the phone number come from separate pools unless you write the glue that keeps them together, and nothing in the library checks whether the values it produced belong to each other.
Reproducibility depends on more than a seed as well. Seeded output is stable for a fixed version of the library, but data pools and internal ordering change between major versions, so an upgrade can reshuffle every fixture even though the seed never moved. If your tests hard-code expected output, a routine dependency bump turns into a fixture migration.
Internal consistency and external correctness are different properties, and a library offers only the first. It can produce a plausible street and a well-shaped postal code without knowing whether the two belong together. The article on identity field consistency is about the second property.
What a hosted generator buys you
The advantage of a hosted or keyed generator is the data model. A generator built on a country dataset can keep division, city and postal code together, which is exactly the class of bug a per-field library cannot help with. The country directory is that dataset, and each record is read from a single source rather than assembled from per-field pools.
Check digits come from per-country implementations where an algorithm exists, and where a country publishes none the validation tool says so rather than implying the number is valid. That honesty is more valuable than it sounds: a generator that labels an entry format-only tells you what your test can and cannot prove.
The costs are operational. A network call in a test is a failure mode in itself, and a build runner without outbound access cannot reach the service at all. The service changing something underneath you is a category of test failure you cannot fix from your own side of the wire.
What an online tool is actually for
An online tool is the right instrument for one-off human work: a QA engineer writing a test case up from a bug report, a designer filling a mock profile, a support agent reproducing a customer’s screenshot, a developer who needs one plausible address to paste into a form to see how the form behaves. Speed is the whole point, and reaching for a library or a command line is slower.
The limits are about the audience. A browser page is not scriptable in a build pipeline, and if it exposes no stable key it is not reproducible, which makes it fine for a sample and unusable as a fixture. Generation that runs entirely in the browser does have one useful property: nothing is uploaded, so a record can go into a demo environment without a data-handling question. The identity generator works on that model, with no sign-up and nothing sent to a server.
How do you choose between them?
The choice collapses into a small decision table once the questions are asked in the right order.
| Situation | Right instrument | Why |
|---|---|---|
| Unit test of business logic, no network | Library | Shape is all the assertion needs |
| Integration fixture whose fields must agree | Keyed generator | Division, city and code come from one record |
| One record for a human to read | Online tool | Nothing to install, no assertion to keep |
| Build runner with no outbound access | Pre-generated fixture file | Determinism beats freshness |
| Migration rehearsal against real distributions | Masked production sample | Only real data has the real shape |
| Demo or sales environment | Generated record | Safe to show, safe to leave lying around |
Read the table as a list of questions rather than a taxonomy. Does the record leave the function under test? Must its fields agree with one another? Does the environment have a network? Each answer moves you one row down the table.
Reproducibility is the deciding property
Everything above reduces to one question: can you get the same record back tomorrow?
A library answers yes if the seed and the version are the same, and if you have written the glue that makes the record internally consistent. A keyed generator answers yes for the same key. An unseeded online tool answers no. For a test fixture only the first two answers are usable, and the second is easier to enforce because the key travels with the test rather than living in a lockfile.
It helps to know which promise you are buying, because reproducible is not one thing. A seed makes a single version’s sequence repeatable, which is what a library offers and why a seed is scoped to a lockfile rather than to a test. A key is stronger: the same key with the same country and gender returns the same record, whatever order the underlying pools happen to sit in. Only the second can be written into a test and left there.
None of these promises that the record is realistic, that the postal code exists, or that the identity number was ever issued. Reproducibility is about getting the same bytes back, not about the bytes being true.
A hybrid strategy that holds up
Most teams end up needing two of the three, and the split is cleaner than it first looks.
Use the library inside unit tests. There the record rarely leaves the function under test, and what you need is a string of the right shape, an email unique within the run, a name that is not empty. Speed matters, the network must stay out of the loop, and if a value changes between runs nobody notices, because the assertion is about behaviour rather than exact bytes.
Use a keyed generator for anything that crosses a boundary. An integration fixture lands in a database, a queue, a shipping service or a payment sandbox, and each of those checks relationships the library never modelled. There you want a whole record for one country, plus a key so the same record comes back on every run.
The seam between the two is the export step: generate the integration set once, commit it beside the key that produced it, and let the build read the file without network access. A schema change is then handled by regenerating rather than by hand-editing rows. Test fixtures for identity data describes how to organise that committed set.
What does switching costs look like?
Switching generators is a fixture migration, and the time goes into the migration rather than into the code change.
Moving from a library to a keyed generator means every fixture built on a seeded sequence has to be re-expressed as a key. The mechanical part is a script that assigns keys and rewrites files. The expensive part is the assertions that quietly depended on the old values: an expected phone number length, an email at a domain the faker happened to use. Those fail for reasons unrelated to the migration and are often mistaken for regressions.
Going the other way trades record-level consistency for offline speed, and every place that relied on a coherent tuple now needs glue you did not previously have to write.
Either direction, the checklist is short. List every fixture. List every assertion that touches generated content. Mark each one as testing a shape or testing a literal. Only the literal assertions need migrating, and if your suite turns out to have almost no shape assertions, that absence is the real finding.
Next steps
Pick one fixture that crosses a boundary today, check whether its fields agree with one another, and give it a key if it does not. Then write down what each fixture guarantees, because a record shaped like a valid address and a record whose parts are internally consistent are different promises, and the gap between them is where test suites drift away from reality.
Every record produced by these tools and described on this page is synthetic test material. It corresponds to no real person, and a generated identity number is not a claim that any document was ever issued.