Комментарии 3
Стратегии тестирования выбираются в зависимости от сложности бизнес логики и выбранной архитектуры.
Например если у тебя "сложная" бизнес логика, несколько моделей хранения данных и ты выбрал CQRS в качестве архитектуры, то логичным звучит выбрать пирамиду тестирования.
Пирамида тестирования, не говорит что важны только unit тесты, она лишь определяет количественное соотношение различных видов тестов.
Судя по коду твоего проекта, ты для реализации бизнес логики сервера выбрал транзакционный сценарий, в этом конкретном случае перевернутая пирамида тестирования это хороший выбор.
Мне кажется, что юнит тесты должны присутствовать всегда (поэтому, в пирамиде тестов их так много), они как знак качества добавленного кода
Дальше, разработчик уже сам решает какие остальные виды тестирования имплементировать. Потому что, здесь уже все зависит от доступного времени и людских ресурсов. И не стоит стремиться к 100% покрытия тестами. Здесь понимание важнее статистики
В случае веб разработки, очень сложно создавать юнит тесты. Из моего опыта могу сказать, что почти все веб проекты которые я видел, были без юнит тестов
В этом примере я тоже не делал юнит тестов из-за простоты самого проекта. Но очень хотел бы услышать мнение веб разработчиков, как бы они добавили юнит тесты в данный проект
Пример создания Full Stack проекта, используя функциональное тестирование как инструмент дизайна