The factory pattern: fixtures that create data on demand
### The limitation of fixed-value fixtures
A regular fixture returns a single, fixed value. Every test that requests it gets the same object:
```python
@pytest.fixture
def user():
return {'username': 'alice', 'email': '[email protected]', 'role': 'admin'}
```
This works fine when one test needs one user. It breaks down as soon as you need variation:
```python
def test_duplicate_username(user):
user_a = user # {'username': 'alice', ...}
user_b = user # same dict — no way to get a different user
assert user_a['username'] != user_b['username'] # FAILS: 'alice' == 'alice'
```
You could write separate fixtures (`user_alice`, `user_bob`, `user_guest`), but this creates fixture proliferation — dozens of nearly identical fixtures for every combination of fields.
## The factory pattern: a fixture that returns a callable
Instead of returning a value, the fixture returns a *factory function*. Tests call the factory with arguments to create as many customised objects as they need:
```python
@pytest.fixture
def make_user():
def _factory(username='alice', email=None, role='user'):
if email is None:
email = f'{username}@example.com'
return {'username': username, 'email': email, 'role': role}
return _factory
```
```python
def test_duplicate_username(make_user):
user_a = make_user(username='alice')
user_b = make_user(username='bob')
assert user_a['username'] != user_b['username'] # PASSES
```
The fixture (`make_user`) runs once and returns the factory function. Each call to `make_user(...)` inside the test creates a fresh dict with the requested fields, using sensible defaults for anything not specified.
## Why defaults matter
Good factory defaults let test code express only the *relevant* variation:
```python
def test_admin_can_delete(make_user):
admin = make_user(role='admin') # only the role matters here
assert can_delete(admin) is True
def test_guest_cannot_delete(make_user):
guest = make_user(role='guest')
assert can_delete(guest) is False
```
The `username` and `email` fields are irrelevant to these tests. With defaults, you don't have to specify them. If you needed 50 test cases, each with a different role, you would not write 50 fixtures — you would parametrize the factory call.
## Faker: realistic test data
The `faker` library generates realistic fake data — names, emails, addresses, phone numbers, lorem ipsum text:
```bash
pip install faker
```
```python
from faker import Faker
fake = Faker()
print(fake.name()) # 'Emily Rodriguez'
print(fake.email()) # '[email protected]'
print(fake.user_name()) # 'jsmith42'
print(fake.pyint(min_value=1, max_value=1000)) # 847
```
Integrating Faker into a factory fixture gives you unique, realistic values by default:
```python
from faker import Faker
import pytest
@pytest.fixture
def make_user():
fake = Faker()
def _factory(**kwargs):
defaults = {
'username': fake.user_name(),
'email': fake.email(),
'first_name': fake.first_name(),
'last_name': fake.last_name(),
}
defaults.update(kwargs)
return defaults
return _factory
```
Now every call to `make_user()` produces a unique user with a different generated username and email, avoiding accidental data collisions between tests.
## Reproducibility: seeding Faker
Faker's output is random by default. If a test fails, reproducing the failure requires the same data. Seed Faker at the start of your test session for reproducible output:
```python
@pytest.fixture(scope='session', autouse=True)
def seed_faker():
Faker.seed(42) # same seed → same sequence of fake data on every run
```
With a fixed seed, the sequence of generated values is deterministic: the 3rd `make_user()` call in your test suite always produces the same username. Without a seed, random data in tests can cause intermittent failures that are hard to reproduce.
## When to use factories vs plain fixtures
| Situation | Use |
|---|---|
| Every test needs the same object | Plain `@pytest.fixture` |
| Tests need objects with slight variations | Factory fixture |
| Tests create multiple objects of the same type | Factory fixture |
| Complex nested structures with many defaults | Factory fixture |
| Simple scalar value (URL, config dict, number) | Plain `@pytest.fixture` |
The factory pattern adds a layer of indirection. Use it when that indirection pays off — when tests genuinely need different instances, not just different references to the same one.
## Composing factories
Factories can call other factories to build nested structures:
```python
@pytest.fixture
def make_order(make_user, make_product):
def _factory(num_items=1, **kwargs):
defaults = {
'user': make_user(),
'items': [make_product() for _ in range(num_items)],
'status': 'pending',
}
defaults.update(kwargs)
return defaults
return _factory
```
```python
def test_order_total(make_order, make_product):
product = make_product(price=10.00)
order = make_order(items=[product, product])
assert calculate_total(order) == 20.00
```
The `make_order` fixture depends on `make_user` and `make_product` — standard fixture chaining. pytest resolves the dependency graph automatically.