Собственно, вопрос в теме. Различных вариаций очень много, из самого больного:
- Контроллер может обращаться к каким угодно сервисам, в т.ч. внешним, или взаимодействовать с базой данных, это можно не учесть и внести неожиданные изменения в боевую БД.
- Классы инициализируются в контроллере а не прокидываются параметрами(Возможно конечно что тут помог бы IoC контейнер, но так исторически сложилось).
ex Software Engineer at Reddit TS/React/GraphQL/Go
тестируем методы контроллеров:
- на предмет валидации данных (пишем тест с валидными и невалидными данными, которые приходят)
- на предмет вызовов других методов (пишем тесты на разные флоу, когда контроллер дергает другие методы и в тесте просто проверяем дернулся ли метод)
А методы которые дергаем соответственно тестирует отдельно, в них как правило какая-то бизнес логика или трансформации может быть задействована.
Если БЛ нет, то есть смысл посмотреть на тестирование с помощью снимков (snapshots), перед коммитом ты записываешь данные, которые пришли из БД, третьих сервисов в third_party.json к примеру, и записываешь результат который отдал твой метод контроллера в отдельный response.json, - все это коммитишь. На staging в тесты подсовываются суррогатные данные из твоих third_party.json вместо вызовов реальных сервисов, прогоняются через логику контроллера и сравниваются с response.json. Соответственно если разработчик меняет логику или взаимодействие, то он должен перезаснять снапшоты.