Reproducible fixtures matter: a failing test should fail the same way on every machine, and a demo should show the same data every time. Both Faker and Real Fake Data can be reproducible — this is not a case where one seeds and the other does not. The difference is in how the seed behaves.
Faker’s model: global and positional
Faker seeds one global generator with faker.seed(n). From then on, each value depends on both the seed and the number of draws made since it was set — the docs are explicit that “generated values are dependent on both the seed and the number of calls that have been made since it was set.” Reset the same seed and the sequence restarts from the top.
That works, but it is positional: insert one extra faker call near the start of your suite and every value after it shifts. And a specific set of relative-date helpers — date.past, date.future, date.recent, date.soon, and a few others — are not reproducible from the seed alone, because they are relative to “today”; you must pass an explicit reference date to pin them. Reproducibility is achievable, but it is coupled to call order and to a few documented caveats.
Real Fake Data’s model: per request
Here the seed travels with the request. Ask for /v1/pl-person?seed=7421 and you get the same person every time — on any machine, in any order, regardless of what your suite generated before it. The seed identifies the record, not a position in a global sequence, so there is nothing to drift.
That makes fixtures composable: each record’s seed is a stable name for that exact record. Add a test above another, reorder your suite, run one test in isolation — the seeded records do not move.
Try it
Set a seed in the Playground, generate, then generate again with the same seed — the identical record comes back every time, on any machine. No key required.
To be precise about Faker
Faker is genuinely reproducible when used carefully — seed it, reset it between tests, and pin a reference date for relative-date helpers, and you get stable output. The contrast is not “seedable vs not”; it is a global, order-sensitive seed versus a per-request seed that names the record directly.