Типа обычно, любая команда может изменить состояние некоторого набора сущностей. Эти сущности я создаю через API или хэлперы, которые сразу пишут в базы в инициализации каждого отдельного теста

Есть сущности, которые просто необходимы для выполнения теста, их состояние не меняется. Например, любая команда выполняется от пользователя, и команды не меняют состояние пользователя (в моём проекте), и тут я использую сиды, чтобы были какие-то пользователи от которых я могу запускать команды.

есть же штуки вроде ex_machina, тесты неплохо бы изолировать, сидировать имеет смысл то, что не изменяется (к примеру у тебя в БД лежат какие-то изменяемые опции для работы приложения)

тесты не внезапно оказываются упавшими. они зелёные, потом ты что-то изменил, и они становятся красные. если тесты покраснели массово - значит ты затронул какую-то массовую деталь

Если они падают на этапе инициализации, то ты изменил структуру

Да, сиды можно использовать только для неизменяемых данных. И даже в этом случае, чаще всего лучше руками сетапить данные

И всё-таки, это никак не помогает изолировать ошибку

Это почему?

Или я не так поняла что такое сиды

ну какбы реализуемо конечно, но секса предстоит очень много. И сиды тут имеется ввиду один seeds.exs на все тесты одновременно с миграцией.

А ок, тогда отзываю свой голос из опроса :D

если Repo.insert! перед каждым тестом, это не сиды, а самый православный путь)

Ex_machina

Ещё как-то балловалась setup_all, но это плохая идея

тоже крутая штука, но фиктуры прямо в тесте нагляднее получаются. Ex_machina добавляет дополнительный уровень сложности/абстракции по генерации данных и ее использование обосновано только когда этих данных надо генерировать реально много

так это ж одно и то же? не?

тебе никто не мешает писать insert  со всеми кишками и нужными полями

на то он и тест

А зачем ex_machina если можно просто Repo.insert!(%{})?

Чтобы спрятать неважные поля и проще читалось

Для того, что бы абстрагировать реализацию