synthetic-data-tool-selector

Overview

Synthetic-data generation has the same conceptual job in every language: produce realistic field values, optionally compose them into typed object graphs. But the canonical library differs per language. This dispatcher routes the team to the right one and shows side-by-side equivalents so a reviewer recognizes the patterns regardless of which language the codebase uses.

When to use

• Starting test-data work on a new project; the team is choosing a library.
• A polyglot codebase needs equivalent fixture patterns across multiple languages.
• An RFC or onboarding doc needs "here's how we do test data, in one page."

If the project is already standardized on one library, defer this skill - go directly to the matching per-tool skill:

• faker-data - Python / JS / Ruby Faker.
• factory-bot-data - Ruby FactoryBot.
• mimesis-data - Python mimesis (alternative to Faker).
• bogus-data - .NET Bogus.

Dispatch by language

Project language?
├── Python
│   ├── Need typed-dict / schema-based bulk generation?
│   │   └── Yes → mimesis-data (faster + typed schema-Field pattern)
│   └── No  → faker-data (Python `faker`, larger ecosystem)
├── JavaScript / TypeScript
│   ├── Browser or Node?  → faker-data (`@faker-js/faker`)
│   └── Need factory orchestration with referential integrity?
│       └── Hand-rolled with Faker as the engine; no canonical factory library yet.
├── Ruby
│   ├── Need factory orchestration?  → factory-bot-data (FactoryBot + Faker as engine)
│   └── Just values?                  → faker-data (`faker-ruby` gem)
├── .NET (C# / F# / VB.NET)
│   └── bogus-data (only canonical option in the ecosystem)
└── JVM (Java / Kotlin / Scala)
    └── Multiple options (datafaker, easy-random, instancio); not covered here.

Dispatch by job

Side-by-side: same fixture in four languages

Generate a single user with name + email + a date of birth in [1980, 2000]. Canonical example (Python / Faker):

from faker import Faker

Faker.seed(42)
fake = Faker()

user = {
    "name":  fake.name(),
    "email": fake.email(),
    "dob":   fake.date_of_birth(minimum_age=23, maximum_age=43),
}

The pattern is identical across libraries; only the API style differs (method calls vs. RuleFor builders). The same fixture in mimesis, faker-js, FactoryBot, and Bogus: references/language-variants.md.

Cross-cutting concerns

Seeding

Every library supports a seed. The convention is:

• In CI: seed with a known constant (e.g. 42) so failures reproduce locally.
• In demo / preview environments: seed with the current date to vary data while staying reproducible per day.
• Never in production (you shouldn't be generating synthetic data in prod anyway).

Version pinning

All four libraries change their PRNG sequence across major versions. Pin the dependency version in CI; document the version in a seeding-conventions doc; revisit on intentional library bumps.

Per-test resetting

Reset the seed in per-test setup (beforeEach / autouse fixture) so each test starts with the same baseline:

Full reset snippets per language: references/language-variants.md.

When NOT to use synthetic data

Faker / FactoryBot / mimesis / Bogus generate realistic-looking positive-path data. The related skills above handle the adversarial, boundary, narrative, and persistent cases.

References

• references/language-variants.md - the four-language fixture equivalents and per-test reset snippets.

Related skills

• faker-data
• factory-bot-data
• mimesis-data
• bogus-data
• malicious-payload-bank, synthetic-pii-generator, boundary-value-generator, negative-test-generator, seed-data-curator - sibling skills for the cases this dispatcher does NOT cover.