synthetic-data-toolkit

Reference detail for synthetic-data-toolkit (opens in new window). Bogus is the canonical .NET test-data generator, ported from faker.js's spirit but typed for the C#-first ecosystem (bogus-readme (opens in new window)). It uses typed Faker<T> builders with fluent .RuleFor calls per property - the .NET equivalent of combining Faker's value generation with a factory library's referential integrity.

When to use

• The project is .NET (C# / F# / VB.NET).
• Tests need typed fixtures matching domain entities.
• The team prefers fluent / strongly-typed APIs over factory-as-DSL (FactoryBot-style).
• xUnit / NUnit / MSTest integration is required.

Install

Install-Package Bogus

(Per bogus-readme (opens in new window); via NuGet.)

For .NET CLI:

dotnet add package Bogus

Authoring

Typed faker builder

using Bogus;

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public DateTime CreatedAt { get; set; }
}

var faker = new Faker<User>()
    .RuleFor(u => u.Id,        f => f.IndexFaker)
    .RuleFor(u => u.Name,      f => f.Name.FullName())
    .RuleFor(u => u.Email,     f => f.Internet.Email())
    .RuleFor(u => u.CreatedAt, f => f.Date.Past());

(Adapted from bogus-readme (opens in new window).)

f is a Faker instance (lowercase) exposing the same data-set modules as the JS / Python ports: f.Name, f.Internet, f.Date, f.Commerce, f.Address, f.Lorem, f.Random, etc.

f.IndexFaker gives a sequential integer per generation - useful for IDs that must be unique within a test.

Strict mode (recommended)

var faker = new Faker<User>()
    .StrictMode(true)
    .RuleFor(u => u.Id,        f => f.IndexFaker)
    .RuleFor(u => u.Name,      f => f.Name.FullName())
    .RuleFor(u => u.Email,     f => f.Internet.Email())
    .RuleFor(u => u.CreatedAt, f => f.Date.Past());

.StrictMode(true) causes Bogus to fail at runtime if any property of T lacks a RuleFor. Recommended - it prevents silent fixture drift when a model adds a new property and the factory isn't updated.

Computed and conditional rules

var faker = new Faker<User>()
    .RuleFor(u => u.FirstName, f => f.Name.FirstName())
    .RuleFor(u => u.LastName,  f => f.Name.LastName())
    .RuleFor(u => u.FullName,  (f, u) => $"{u.FirstName} {u.LastName}")    // computed from already-set fields
    .RuleFor(u => u.IsActive,  f => f.Random.Bool(0.9f));                   // 90% active

The second-argument-form of RuleFor ((f, u) => ...) lets a rule reference already-generated properties on the same instance - useful for derived fields.

Generation

Per bogus-readme (opens in new window):

var oneUser   = faker.Generate();           // single
var hundred   = faker.Generate(100);         // list of 100
var lazyTen   = faker.GenerateLazy(10);      // IEnumerable<User>; deferred

Use GenerateLazy when seeding a database with thousands of rows - it streams instead of materializing.

Seeding

var faker = new Faker<Order>()
    .UseSeed(1338)
    .RuleFor(o => o.Item, f => f.Commerce.Product());

(Per bogus-readme (opens in new window).)

UseSeed(int) makes generation reproducible across runs - same seed produces same data. Mirror the faker-data seeding guidance: seed in test setup so failures reproduce.

For globally seeding the underlying randomizer (affecting any non-Faker<T> direct calls):

Randomizer.Seed = new Random(42);

Locale support

var faker = new Faker<User>("de")
    .RuleFor(u => u.Name, f => f.Name.FullName());

The locale code in the constructor switches data sets. Bogus ships 30+ locales; supported codes match Faker's conventions (en, de, ja, ko, ru, pt_BR, etc.).

Test framework integration

xUnit

public class UserTests
{
    private readonly Faker<User> _userFaker = new Faker<User>("en")
        .UseSeed(42)
        .StrictMode(true)
        .RuleFor(u => u.Name,  f => f.Name.FullName())
        .RuleFor(u => u.Email, f => f.Internet.Email());

    [Fact]
    public void User_HasName()
    {
        var user = _userFaker.Generate();
        Assert.NotEmpty(user.Name);
    }
}

NUnit and MSTest wire identically - Bogus is framework-agnostic.

Anti-patterns

Limitations

• .NET-only. For other languages, see faker-data (Python/JS/Ruby), mimesis.md (opens in new window) (Python), and factory-bot.md (opens in new window) (Ruby).
• PRNG sequence varies across major versions. Pin the package version for deterministic tests.
• No native factory orchestration for graphs. Composing a User with three Orders requires explicit chaining; there's no FactoryBot-style after(:create) block.

References

• bogus-readme (opens in new window) - canonical: install, Faker<T>, RuleFor, Generate / GenerateBetween / GenerateLazy, UseSeed.
• faker-data - the family default for plain field values.

Reference detail for synthetic-data-toolkit (opens in new window). FactoryBot (formerly factory_girl) is the canonical Ruby fixture-factory library - it builds object graphs with referential integrity that raw faker-data cannot (factory_bot-readme (opens in new window)).

The split:

• Faker generates field values (Faker::Name.name).
• FactoryBot orchestrates object creation (create(:user, :admin, posts_count: 3)) - including sequence-based unique IDs, associations between models, and trait composition.

When to use

• The project is Ruby (Rails or pure Ruby).
• Tests need structured fixtures: a User with three Posts and a Profile, all linked correctly.
• The test suite uses RSpec or Minitest - both are first-class.
• The team wants "intent-revealing" fixture names (create(:admin)) rather than per-field overrides.

How to use

1. Add factory_bot_rails (Rails) or factory_bot to the test group and require it.
2. Define one base factory per model in spec/factories/, one attribute block each.
3. Add trait blocks for variants (:admin, :with_posts) instead of separate variant factories.
4. Wire Faker into attribute blocks for randomized values; use .unique where uniqueness matters.
5. Pick a build strategy per test: build_stubbed for unit, build for no-DB, create for persistence.
6. Include FactoryBot::Syntax::Methods in the RSpec / Minitest config to call create(:user) directly.
7. Call the factory in the test and assert on the returned object.

Install

gem install factory_bot

For Rails projects, prefer the Rails-specific gem with auto-loading:

# Gemfile
group :test do
  gem 'factory_bot_rails'   # adds Rails-specific helpers and auto-loads spec/factories/
end

(Per factory_bot-readme (opens in new window).)

Authoring

Basic factory

# spec/factories/users.rb
FactoryBot.define do
  factory :user do
    name  { "John Doe" }
    email { "john@example.com" }
  end
end

(Per factory_bot-readme (opens in new window).)

Each attribute is a block - the block is evaluated lazily at object creation, so Faker::Name.name re-runs per create call.

Sequences

For unique values across factory invocations:

sequence :email do |n|
  "user#{n}@example.com"
end

factory :user do
  email   # uses the sequence
end

(Per factory_bot-readme (opens in new window).)

Associations

factory :post do
  title  { "Hello" }
  body   { "World" }
  user   # implicit reference to a user factory
end

# OR explicit association
factory :post do
  user   # short form
  # association :user, factory: :admin   # explicit form
end

# Has-many: build N posts from a user factory
factory :user do
  name { "John" }
  after(:create) do |user|
    create_list(:post, 3, user: user)
  end
end

Traits

Traits compose mix-ins onto a base factory:

factory :user do
  name  { "John Doe" }
  email { "john@example.com" }

  trait :admin do
    role  { "admin" }
  end

  trait :with_posts do
    after(:create) do |user|
      create_list(:post, 3, user: user)
    end
  end
end

# Apply one or more traits at create time
FactoryBot.create(:user, :admin, :with_posts)

(Per factory_bot-readme (opens in new window).)

Traits are the canonical way to keep factory bodies DRY - instead of ten variant factories (:admin_user, :premium_user, :admin_premium_user, …), one base factory plus N traits composes to all variants.

Build strategies

Per factory_bot-readme (opens in new window), FactoryBot supports three:

Speed hierarchy: build_stubbed >> build >> create. Use the weakest one that still tests what you need.

build(:user)          # Unsaved User instance
create(:user)         # Persisted User (and any associations)
build_stubbed(:user)  # Fake-persisted User; `id` is set, `new_record?` is false

Integrating with Faker

Plug Faker into the factory body for randomized values:

require 'faker'

FactoryBot.define do
  factory :user do
    name  { Faker::Name.name }
    email { Faker::Internet.unique.email }   # `.unique` enforces uniqueness across factory invocations
    age   { Faker::Number.between(from: 18, to: 80) }
  end
end

Faker::Internet.unique (and other unique helpers) tracks generated values per session and raises if exhausted. Use this instead of a sequence when you want both randomness and uniqueness.

Test framework integration

RSpec

# spec/spec_helper.rb (or rails_helper.rb for Rails)
RSpec.configure do |config|
  config.include FactoryBot::Syntax::Methods   # enables `create(:user)` instead of `FactoryBot.create(:user)`
end

# spec/users_spec.rb
RSpec.describe User do
  it 'has a name' do
    user = create(:user)
    expect(user.name).to be_present
  end
end

Minitest

# test/test_helper.rb
class ActiveSupport::TestCase
  include FactoryBot::Syntax::Methods
end

Per factory_bot-readme (opens in new window); both syntaxes mirror the same DSL - only the test-framework hookup differs.

Worked example

A test needs an admin user that owns three posts. Define the factory with two traits and Faker-backed values:

# spec/factories/users.rb
FactoryBot.define do
  factory :user do
    name  { Faker::Name.name }
    email { Faker::Internet.unique.email }

    trait :admin do
      role { "admin" }
    end

    trait :with_posts do
      after(:create) { |user| create_list(:post, 3, user: user) }
    end
  end
end

Compose both traits in one intent-revealing call:

RSpec.describe User do
  it 'admin owns three posts' do
    user = create(:user, :admin, :with_posts)
    expect(user.role).to eq('admin')
    expect(user.posts.count).to eq(3)
  end
end

create persists the user and, via the :with_posts after(:create) hook, its three posts - one line instead of six lines of manual setup.

Anti-patterns

Limitations

• Ruby-only. For other languages: factory_boy (Python), fishery (TS), Bogus (.NET - see bogus.md (opens in new window)), MockK (Kotlin).
• Auto-load only with factory_bot_rails. Pure Ruby projects must require factory files manually.
• No native support for has_many through:. You can express it with after(:create) blocks, but the syntax is hand-rolled.
• Sequence resets on test reload. A long-running suite generates user1@example.com ... user5000@example.com. If asserting on the n-th sequence value, your test breaks when run in isolation.

References

• factory_bot-readme (opens in new window) - canonical: install, factory definition, traits, associations, sequences, build / create / build_stubbed strategies.
• faker-data - Ruby Faker (the value engine for FactoryBot fields).
• seed-data-curator - downstream workflow consuming FactoryBot for E2E suite seeds.

Generate a single user with name + email + a date of birth in [1980, 2000]. The pattern is identical across libraries; only the API style differs (method calls vs. RuleFor builders). The Python (Faker) canonical version is inline in SKILL.md.

Python (mimesis)

from mimesis import Generic, Locale

g = Generic(Locale.EN, seed=42)

user = {
    "name":  g.person.full_name(),
    "email": g.person.email(),
    "dob":   g.datetime.date(start=1980, end=2000),
}

JS / TS (faker-js)

import { faker } from '@faker-js/faker';

faker.seed(42);

const user = {
  name:  faker.person.fullName(),
  email: faker.internet.email(),
  dob:   faker.date.birthdate({ min: 23, max: 43, mode: 'age' }),
};

Ruby (FactoryBot + Faker)

FactoryBot.define do
  factory :user do
    name  { Faker::Name.name }
    email { Faker::Internet.unique.email }
    dob   { Faker::Date.birthday(min_age: 23, max_age: 43) }
  end
end

# Use:
Faker::Config.random = Random.new(42)
user = FactoryBot.create(:user)

.NET (Bogus)

var faker = new Faker<User>("en")
    .UseSeed(42)
    .RuleFor(u => u.Name,  f => f.Name.FullName())
    .RuleFor(u => u.Email, f => f.Internet.Email())
    .RuleFor(u => u.Dob,   f => f.Date.Past(43));

var user = faker.Generate();

Per-test resetting

Reset the seed in beforeEach (Vitest / Jest / pytest / RSpec) so each test starts with the same baseline:

import { faker } from '@faker-js/faker';

beforeEach(() => { faker.seed(42); });

@pytest.fixture(autouse=True)
def reset_faker():
    Faker.seed(42)

RSpec.configure do |c|
  c.before(:each) do
    Faker::Config.random = Random.new(42)
  end
end

// xUnit fixture or per-test setup
[Fact]
public void Test()
{
    var faker = new Faker<User>().UseSeed(42)...;
}

Reference detail for synthetic-data-toolkit (opens in new window). Mimesis is a Python test-data generator that's "widely recognized as the fastest data generator among Python solutions" with full type hints for editor autocompletion (mimesis-readme (opens in new window)).

The library supports 46 locales (mimesis-readme (opens in new window)) and exposes both per-provider methods (Person.full_name()) and a schema-based generator for typed-dict shapes.

When to use

• The project is Python and the team values mimesis's speed (~10-100x faster than Faker on bulk generation, per the upstream benchmarks).
• Type hints matter - mimesis exposes typed return values that show up in IDE autocomplete.
• The project needs strong locale coverage - mimesis ships 46 locales; Faker ships 70+ but many are Faker-thin (only a few providers populated).
• Schema-based generation is a fit - mimesis's Schema / Field pattern produces typed dicts directly.

If the team is already standardized on Faker, switching is rarely worth it - see faker-data. If the team needs factory orchestration with referential integrity, pair mimesis with factory_boy (or use FactoryBot - see factory-bot.md (opens in new window) - in Ruby projects).

Install

pip install mimesis

(Per mimesis-readme (opens in new window).)

Authoring

Per-provider usage

from mimesis import Person, Address, Internet, Datetime
from mimesis.locales import Locale

person = Person(Locale.EN)
person.full_name()                 # 'Brande Sears'
person.email(domains=['example.com'])   # 'roccelline1878@example.com'
person.gender()
person.title()

address = Address(Locale.EN)
address.full_address()             # '123 Main St, Springfield, IL 62701'
address.city()
address.country()

internet = Internet()
internet.url()
internet.ip_v4()
internet.user_agent()

dt = Datetime()
dt.datetime()
dt.date()
dt.formatted_datetime()

(Adapted from mimesis-readme (opens in new window).)

Generic - one entry point per locale

from mimesis import Generic
from mimesis.locales import Locale

g = Generic(Locale.EN)
g.person.full_name()
g.address.city()
g.internet.email()

Generic aggregates every provider under one instance - preferred when a fixture needs values from multiple providers; avoids constructing one provider per type.

Schema-based - typed-dict generation

from mimesis import Field, Schema, Locale

field = Field(Locale.EN)

# Build one row's worth of data
def schema():
    return {
        "id": field("uuid"),
        "name": field("person.full_name"),
        "email": field("person.email"),
        "created_at": field("datetime.datetime"),
        "address": {
            "city": field("address.city"),
            "zip": field("address.postal_code"),
        },
    }

# Generate a list of rows
generator = Schema(schema=schema, iterations=1000)
data = generator.create()    # → list of 1000 dicts

(Adapted from mimesis-readme (opens in new window) schema documentation.)

The schema/field pattern is mimesis's distinguishing feature - it produces typed-dict shapes without per-field method calls, which makes it convenient for bulk fixture generation (e.g. seeding a test DB with 10k rows).

Locale support

from mimesis import Person
from mimesis.locales import Locale

Person(Locale.EN).full_name()    # 'Brande Sears'
Person(Locale.JA).full_name()    # '広橋 美月'
Person(Locale.RU).full_name()    # 'Анастасия Иванова'
Person(Locale.DE).full_name()    # 'Klaus Müller'

Per mimesis-readme (opens in new window), 46 locales are supported. Full list at mimesis.name/latest/locales.html (opens in new window).

Seeding for determinism

from mimesis import Generic
from mimesis.locales import Locale

g = Generic(Locale.EN, seed=12345)
g.person.full_name()    # deterministic based on seed

Pass seed= at provider construction; subsequent calls are deterministic. Same as faker-data, seed in tests so failures reproduce locally.

Pairing with factory_boy

Mimesis can be the value engine for factory_boy:

from factory import Factory, LazyFunction
from mimesis import Person, Locale
from myapp.models import User

person = Person(Locale.EN, seed=42)

class UserFactory(Factory):
    class Meta:
        model = User

    name  = LazyFunction(person.full_name)
    email = LazyFunction(lambda: person.email())

LazyFunction ensures each factory instantiation re-calls the mimesis method - getting a new value per fixture, not a single shared one.

Anti-patterns

Limitations

• Smaller community than Faker. Fewer Stack Overflow answers, fewer third-party providers.
• PRNG sequence varies across major versions. Pin the version in CI for deterministic tests across runs.
• No native factory orchestration. You still need factory_boy (or hand-rolled equivalents) for referential integrity.

References

• mimesis-readme (opens in new window) - install, providers, Generic, Schema/Field, 46 locales.
• mimesis docs - https://mimesis.name/
• faker-data - Python Faker alternative.