Привет всем! 👋 Я тут недавно пересматривала наш пайплайн и поймала себя на мысли, что мы всё ещё используем статические сиды для тестов, которые живут в базе уже полгода. Это удобно, когда нужно быстро прогнать smoke-тесты, но каждый раз, когда меняется схема, я ловлю флешбэки от падающих тестов. Кто-то тоже так мучается или уже перешёл на генерацию данных прямо внутри тестов, например, через фабрики или временные фикстуры?
Мне вот интересно, как вы балансируете между скоростью прогона и изоляцией? Ведь если сиды общие, то параллельные тесты могут конфликтовать. А если генерировать всё на лету, то время выполнения растёт. Я пробовала оба подхода, но пока не нашла золотую середину. Может, кто-то использует гибридные схемы или вообще выносит тестовые данные в отдельный контейнер? Хочу услышать реальные кейсы и грабли, на которые вы наступали! 😅
Привет! Полностью поддерживаю — статические сиды, живущие в базе месяцами, это боль. У нас в проекте была похожая история: сиды разрослись до состояния «магического леса», где изменение любого поля могло уронить десяток тестов, а понять, почему упало, можно было только через дебаг с пристрастием. Я за гибридный подход: для smoke-тестов и критичных сценариев оставляем минимальный набор сидов (буквально 10-15 записей, которые редко меняются), а для всего остального используем фабрики с генерацией на лету, но с обязательным транзакционным откатом после каждого теста.
Ключевой момент — изоляция. Мы завернули фабрики в утилиту, которая автоматически оборачивает каждый тест в транзакцию, так что даже при параллельном прогоне данные не пересекаются. Это добавляет пару миллисекунд на тест, но зато убирает все конфликты. Если хочется скорости, можно кэшировать созданные объекты в рамках одного сьюта, но только если тесты не мутируют эти данные. А отдельный контейнер с тестовой БД — это уже из разряда «когда совсем всё плохо с производительностью», но тогда приходится думать о версионировании схемы и миграциях, что само по себе отдельный квест. В общем, мой совет: не храните в сидах ничего, что может измениться из-за бизнес-логики, и всегда имейте возможность пересоздать окружение с нуля.
