Для небольших проектов вариант может хорошо заходить, но с увеличением проекта и количества тестов базовый набор будет расти, и правки в нем могут каскадно валить кучу тестов.
У меня был как раз такой опыт. Меняем контракты — ничего не компилится и нужно править тесты в 20 местах. Или еще хуже, компилится, но тесты вываливаются с какой-нибудь общей проблемой, типа HTTP 500 или неинформативным исключением.
Один из способов с этим справиться — по максимуму убирать все неважные детали данных за пределы тестов. Самое сложное — описать свою схему/модель такой структурой, которая бы с одной стороны была полной, т.е. покрывала все сущности и удовлетворяла все зависимости, а с другой — не принимала в себя ничего лишнего, ну и чтобы с ней было удобно работать.
В моем примере, это PackageEntry, который содержит только связи других сущностей с Package. В теле теста мы описываем только табличку значений, из которых делаем PackageEntry — по сути, только говорим сколько и каких дефолтных объектов нам нужно — и оверрайды полей, а все остальные трансформации происходят за пределами теста. Этот пример будет хорошо работать с неплотными данными, если бОльшая часть полей в бОльшей части объектов не имеет значение в конкретном тесте (справочные данные, а не какая-нибудь хардкорная статистика).
Если модель поменяется некардинально (изменятся какие-то поля или добавятся новые сущности), то фикстуры, в целом, останутся актуальными — нужно будет только поправить конвертацию ключей в строки (Enrich) и линзы для оверрайдов. Если изменения такие, что прям таблицы удаляются из базы, то будут проблемы, но мне кажется такое бывает крайне редко. Если поменяется бизнес-логика — правим табличку с данными.
А от того, чтобы проверять руками, почему посыпались тесты, неплохо спасают подробные логи. Чем больше тесты несут читабельной информации о себе и о системе, тем легче с ними работать и тем они полезнее.
Для небольших проектов вариант может хорошо заходить, но с увеличением проекта и количества тестов базовый набор будет расти, и правки в нем могут каскадно валить кучу тестов.
У меня был как раз такой опыт. Меняем контракты — ничего не компилится и нужно править тесты в 20 местах. Или еще хуже, компилится, но тесты вываливаются с какой-нибудь общей проблемой, типа HTTP 500 или неинформативным исключением.
Один из способов с этим справиться — по максимуму убирать все неважные детали данных за пределы тестов. Самое сложное — описать свою схему/модель такой структурой, которая бы с одной стороны была полной, т.е. покрывала все сущности и удовлетворяла все зависимости, а с другой — не принимала в себя ничего лишнего, ну и чтобы с ней было удобно работать.
В моем примере, это
PackageEntry, который содержит только связи других сущностей сPackage. В теле теста мы описываем только табличку значений, из которых делаемPackageEntry— по сути, только говорим сколько и каких дефолтных объектов нам нужно — и оверрайды полей, а все остальные трансформации происходят за пределами теста. Этот пример будет хорошо работать с неплотными данными, если бОльшая часть полей в бОльшей части объектов не имеет значение в конкретном тесте (справочные данные, а не какая-нибудь хардкорная статистика).Если модель поменяется некардинально (изменятся какие-то поля или добавятся новые сущности), то фикстуры, в целом, останутся актуальными — нужно будет только поправить конвертацию ключей в строки (
Enrich) и линзы для оверрайдов. Если изменения такие, что прям таблицы удаляются из базы, то будут проблемы, но мне кажется такое бывает крайне редко. Если поменяется бизнес-логика — правим табличку с данными.А от того, чтобы проверять руками, почему посыпались тесты, неплохо спасают подробные логи. Чем больше тесты несут читабельной информации о себе и о системе, тем легче с ними работать и тем они полезнее.