Как использовать библиотеки вроде factory_boy или faker для генерации тестовых данных и в чём их преимущество перед ручным созданием объектов в каждом тесте?

Короткий ответ

factory_boy описывает фабрику для модели с разумными значениями по умолчанию (в том числе случайными через faker), и тест может создать объект, переопределив только те поля, которые важны для конкретного сценария, вместо заполнения всех обязательных полей вручную.

Как это работает подробнее

Фабрика — это класс, декларативно описывающий, как собрать объект модели (ORM-модели, Pydantic-схемы и т.п.) с значениями по умолчанию; faker генерирует реалистичные случайные данные (имена, email, даты). Вызов Factory() или Factory(field=value) создаёт объект, переопределяя только нужные поля.

Пример кода

testing_example_313.pyКопировать

import factory
class UserFactory(factory.Factory):
    class Meta:
        model = User
    id = factory.Sequence(lambda n: n)
    name = factory.Faker("name")
    email = factory.Faker("email")
    is_vip = False
def test_vip_user_gets_discount():
    user = UserFactory(is_vip=True)  # остальные поля заполнены автоматически
    assert calculate_discount(100, user.is_vip) == 80

Что использовать на практике

• Практика. Это особенно полезно, когда модель имеет много обязательных полей, не относящихся к сути теста — тест остаётся сфокусированным на том, что он действительно проверяет, а не на заполнении шаблонного boilerplate. Для БД-ориентированных фабрик (factory_boy с SQLAlchemyModelFactory/DjangoModelFactory) можно сразу сохранять объект в тестовую БД.

Подводные камни

• Риск. Полагаться на случайные значения faker там, где тесту нужен детерминированный результат (например, сортировка по имени) — стоит либо зафиксировать seed, либо явно переопределить нужные поля значениями, важными для проверки. Создавать фабрики со скрытой сложной логикой внутри, из-за чего тест, использующий фабрику, становится непрозрачным в том, какие именно данные реально были созданы и почему.