## TL;DR

Factories build valid objects with sensible defaults and per-test overrides. Define one factory per model, override only what the test needs, and use traits for variants.

## Error

```text
(Not an error; a technique guide. The problem it solves: brittle, duplicated fixture setup.)
```

## Steps

1. Pick a factory library (factory_bot, factory_boy, fishery, rosie). Expected: one library chosen.
2. Define factories with valid defaults for every required field. Expected: `create(:user)` just works.
3. Override per test: `create(:user, admin: true)`. Expected: minimal, readable setup.
4. Use traits for common variants (`:with_orders`). Expected: named variants, not inline blobs.
5. Prefer `build` over `create` when persistence is unneeded. Expected: faster tests.

## When to use

- Replacing static fixtures.
- Complex object graphs in tests.

## When not to use

- Truly static reference data (fixtures are fine).
- You need prod-shaped bulk data (separate concern).

## Tool compatibility

- factory_bot (Ruby), factory_boy (Python), fishery (JS).

## Variant phrasings

### Test factories vs fixtures

Factories win for variation; fixtures for static reference.

### Factory pattern in tests

The general technique; defaults plus overrides.

## Why it happens

Fixtures rot and duplicate. Factories generate fresh, valid objects with local overrides, keeping tests readable.

## Edge cases

- Factories can hide required setup; keep defaults minimal and explicit.
- Circular factory dependencies need lazy evaluation.
- `create` hits the DB; `build_stubbed` is faster for pure unit tests.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rGcB6d1sF5-EdvldgIjt6g