Найти альтернативы миксеру

[e-stepanov]

Периодически приходится обходить всякие недоработки миксера: генерация случайных значений, нет нормальной поддержки роутеров баз данных, местами некорректно генерирует значения (к примеру, у меня был проблемы с PositiveIntegerField - генерировались отрицательные значения), не умеет из коробки работать с наследованием моделей (которое реальное, а не абстрактное).

В репозитории последний коммит - 3 года назад. В issue тоже нет никакой активности.

Может подумаем над альтернативами?

[e-stepanov]

@kazqvaizer вот эта штука у меня болит, добавил для обсуждения.

[kazqvaizer]

Как вариант - https://github.com/model-bakers/model_bakery

[e-stepanov]

Как вариант - https://github.com/model-bakers/model_bakery

Я еще немного работал с https://factoryboy.readthedocs.io/, для него есть pytest плагин https://pytest-factoryboy.readthedocs.io (правда не уверен, что он живой). В целом мне он нравится, можно будет тоже присмотреться.

[nkiryanov]

Я еще немного работал с https://factoryboy.readthedocs.io/

Подскажи, остался пример как фикстуры генерировал?
Мой опыт (3+ года назад) говорит что там нужно для каждого поля самому писать генератор. Посмотрел документацию и вроде ничего не поменялось, но может это я туплю.

Пока смотрю в сторону model_bakery — у них похожий API на миксер.
Хочу прикрутить в проект где много тестов и посмотрю как много отвалится, а потом решать.

Из существенных различий mixer и model_bakery:

• mixer генерит случайные данные через faker. Кажется это плюс, т.к. данные больше похоже на реальные, но периодически ловим баги когда тестов больше 500
• model_backery юзает написанные случайные генераторы. Как плюс — нет зависимостей и багов с повторяющимися данными должно быть меньше, но данные не похоже на реальные

[kazqvaizer]

данные не похоже на реальные

Не вижу с этим особых проблем, учитывая, что у нас принята практика внятно описывать тестируемые фикстуры. Т.е. мы явно пишем:

@fixture()
def some(factory):
   return factory.some(name='Sarah')

def test_name_changed(some):
   some.change()

   assert some.name != 'Sarah'

Вот если бы мы полагались на автогенератор в подобных фикстуре выше, то да, нам было бы важно.

Если же не указываем явно, то нам и без разницы, что внутри, главное чтоб в строковом поле строки, в числовых - числа и тп.

[e-stepanov]

Мой опыт (3+ года назад) говорит что там нужно для каждого поля самому писать генератор.

Да, сейчас такая же история. Меня это не особо сильно напрягает: побольше кода, но зато более четко управляешь логикой генерации.

Пока смотрю в сторону model_bakery — у них похожий API на миксер.

Вот это более веский аргумент в пользу model_bakery, потому что у factory_boy действительно отличается подход, к нему нужно привыкать и скорее всего придется отработать новые практики написания кода.

[nkiryanov]

Периодически приходится обходить всякие недоработки миксера: генерация случайных значений, нет нормальной поддержки роутеров баз данных, местами некорректно генерирует значения (к примеру, у меня был проблемы с PositiveIntegerField - генерировались отрицательные значения), не умеет из коробки работать с наследованием моделей (которое реальное, а не абстрактное).

fyi @e-stepanov переехали на model_bakery + faker (#827)
+ сам процесс переезда не сложный — для теста переезжали с mixer в проекте с 700+ тестами и прошло легко.

У меня нет уверенности, что закроет 100% проблем выше — у model_bakery концепт поведения проще, чем у mixer.
Например если нужны уникальные поля, то может потребоваться написать свой генератор и это что-то среднее между mixer и factory_boy и по-моему это прямо ок.

Из того что мне оч понравилось: model_bakery будет сообщать (падать) когда в фабрику передают поле которого нет у модели.

[e-stepanov]

model_bakery будет сообщать (падать) когда в фабрику передают поле которого нет у модели.

Это очень полезная штука! В миксере мне тоже этого не хватало: периодически напарывался, что ошибся в названии поля, а миксер молча отрабатывал.