Faker review: what it is and how to use it for test data

Every Faker instance combines a pseudo-random number generator with locale definitions: lists of first names, street suffixes, company words and patterns for phone numbers and postcodes. A method such as faker.person.lastName() draws from those lists using the generator, so with the same seed, the same Faker version and the same sequence of calls, the output is identical. That is the basis of reproducibility, and also of its fragility: adding one extra call earlier in a test shifts every value after it, and a Faker release that changes a list changes the data a seed produces.

Methods are grouped into modules: basic types such as number, string, date and datatype, topic modules such as person, location, internet, finance, commerce and company, and helpers for working with your own data. The default faker export is English; each built-in locale has its own pre-built instance, such as fakerDE or fakerEN_GB, and new Faker({ locale: [...] }) builds a custom instance from a list of locale definitions checked in order, so a custom definition can override part of a locale and fall back to English and base for the rest. simpleFaker offers the locale-free modules without loading locale data.

Methods such as faker.date.past, date.future, date.recent, date.soon, git.commitEntry and string.uuid with version 7 generate values relative to a reference date, which defaults to now. A seed alone therefore does not make them reproducible: tomorrow the same seed yields different dates. Passing refDate to a call, or calling faker.setDefaultRefDate once, fixes the reference so date output becomes deterministic. This is the most common reason a seeded test still fails differently on different days.

Faker began as a Perl library in 2004 and the idea was ported widely. @faker-js/faker is the JavaScript port, taken over by a community team in January 2022 after the original faker.js maintainer deleted the project; the unscoped faker package on npm was left at a version 6.6.6 that contains almost nothing. Faker for Python, faker-ruby, Datafaker for Java and FakerPHP are separate projects with their own APIs, versions and seeding rules, so code and advice do not transfer between them unchanged.

Wrap Faker in one factory per domain object, in a shared folder such as test/factories, and never call Faker directly in test bodies. The factory generates related fields from each other, a first name before the email that uses it, so records are internally consistent. Overrides let each test pin only what it asserts on: a test about the pro plan passes plan: pro and leaves everything else random. That keeps tests short, makes intent obvious, and puts the knowledge of what a valid user looks like in one place, so a new mandatory field means one change rather than a hundred.

A single shared faker instance, seeded once, makes data depend on test order: run one test alone and its data changes. Give each test its own instance and seed it, using a seed from the environment when reproducing a failure or a fresh random one otherwise, and record the seed where the report shows it. The Playwright fixture below does this; the same pattern works in a Vitest or Jest beforeEach. To reproduce a failure, rerun the test with FAKER_SEED set to the logged value, on the same Faker version.

Faker methods do not promise unique values, and some draw from small lists; faker.animal.type has 44 options. Even full names repeat sooner than intuition suggests. For a batch generated at once, faker.helpers.uniqueArray returns distinct values. For data created across tests and runs against a shared database, add a run-specific token: a short random string per run, or the CI run ID, placed in the email local part or a name suffix. That guarantees uniqueness and makes cleanup trivial, because every record from a run shares the token.

Realistic data can still do harm. Generated emails on common webmail domains may belong to real people, so use exampleEmail or a provider on a domain you control. Phone numbers are random digits in a valid format and can be real numbers, so never let staging send SMS to generated numbers. Generated card numbers and IBANs are for format validation only, and payment sandboxes require their documented test numbers instead. Above all, use Faker instead of copying production records: generated data has no data protection obligations, while a copied customer table carries all of them into every test environment.

Choose the locale that matches the market under test: fakerEN_GB produces British postcodes and phone formats, fakerDE German addresses, fakerJA Japanese names. For domain-specific values, define a small custom locale and put it first in the list, so it overrides only what you specify and falls back to built-in locales for everything else. A custom domain_suffix of test, for example, makes generated domain names and URLs non-routable; note that the key uses the snake_case name of the locale data, and that internet.email still draws on free webmail providers, so keep using exampleEmail for addresses. Keep custom definitions in the factories folder so the whole suite shares them.