Комментарии 5
мы получим переусложненный тест с множеством условий запуска тех или иных проверок и перегруженным дата-провайдером. В итоге, в таком тесте будет разобраться сложнее, чем в проверяемом методе.
Есть такое (( Так и пишу. Очень сложные тесты выходят с подключением к базе, с проверкой, с вызовом сервисом и потом не могу сам понять логику
По моему мнению, писать юнит тесты особо смысла не имеет, если у вас маленький/средний проект. Если нет какого-нибудь DDD в проекте.
Для меня Unit-тесты, это тесты которые нужно писать если создаешь фреймворк/библиотеку, когда имеется четкий контракт поведения класса. Ибо тогда у нас имеется состояние которое нужно проверять. Убедиться что работают предусловия, постусловия и инварианты
Зачем писать юнит-тесты на модели, на контроллеры и т.п, если все это уже написано/проверено самим разработчиком либы/фрейма?
В обычных проектах структура +- такова: Репозиторий, Сервис и ДТО. Обычно репозиторий и Сервис не имеет состояние, только DTO, но писать тесты для ДТО?, проверять сеттер и геттер?
Обычно для проектов пишу Feature тесты или Функциональные тесты (по разному их называют). Или может быть я не встречал таких кейсов
Конечно, если у вас проект на три таблицы по пять полей. DTO - небольшой класс к несколькими публичными полями. Entity представляют из себя анимичные модели и все геттеры и сеттеры генерированы автоматичеси. В пректе всего пара сервисов, в которых нет бизнес логики, поскольку они просто прокси между контроллером и репозиторием. То вы правы. Не тратьте время на интеграционные и Unit тесты. Достаточно нескольких функциональных тестов, покрывающих только позитивное флоу.
Всё же предположу, что вы работаете с несколько более крупными проектами.
Почему "если нет DDD, то и юнит тесты писать не нужно"? Контракт - это не только и не столько интерфейс. Это в первую очередь ожидаемый и стабильный результат работы вашего кода. Если ваш код выдаёт стабильный результат работы, на который рассчитываю остальные, значит у вас есть контракт. И не важно как оформлен ваш код. ООП, функциональный стиль или "макароны".
Как вы проверяете, что весь ваш код работает правильно? Конечно, не стоит тестировать код фреймворка. Но как вы гарантируете, что нет банальных опечаток при объявлении сервисов или в анотациях к полям Entity и доктрина всё сохраняет даже в необязательных полях. Добавили новую зависимость в сервис, а контейнер смог его собрать?
Давайте пока остановимся на сервисах. Если вы используете только функциональные тесты. Вы проверяете только позитивный флоу? Как быть с крайними значениями и заведомо некорректными данными? Вы проверяете обработку таких данных? Юнит тесты прекрасно пишутся и на сервисы. Не только на DTO и Entity. Сервису всё равно откуда он получил данные. Из настоящего репозитория или из мока. И куда он их отправит ему тоже всё равно. И Unit тесты здесь подходят как нельзя лучше.
Если вы в тестах работаете с базой (интегационные тесты и функциональные), то тесты проходят гораздо медленнее потому, что данные нужно сперва записать в базу, потом получить. И для идентификации данных не всегда получается использовать поле с индексом. Значит запросы будут работать ещё медленнее.
Теперь представим, что у вас между контроллером и репозиторием не один сервис-прокси (фасад), а несколько сервисов взаимодействующих друг с другом. В реальных проектах их может быть 5, 10 или больше. Кто-то из них в базу сходит за дополнительными данными. Кто-то на API внешнего сервиса. И в каждом своя часть бизнес логики. Сколько наборов тестовых данных вам понадобится, чтобы проверить все варианты их работы? И нужно, чтобы они не конфликтовали в базе данных. Значит понадобится загружать данные в базу, удалять и снова загружать. И я ещё не упомянул работу парам-конвертеров, валидацию входящих данных, валидацию итогового состояния Entity и прочие вспомогательные обработки, которые многие не учитывают.
Даже не хочу представлять в какой кошмар превратится проверка работы одного такого роута.
А Unit тесты вместе с моками позволяют проверить работу каждого сервиса изолированно.
В том числе и об этом идёт речь в статье. Уменьшайте скоуп проверки в каждом отдельном тесте.
Для coverage xdebug не так хорош. Есть же PCOV https://pecl.php.net/package/pcov
На больших проектах прирост скорости генерации кратный
Публикации
Тестирование PHP проектов на примере Symfony