отвественный за парсинг и валидацию параметров запроса, аутентификацию и подготовку параметров для сервиса. сервис в свою очередь делает уже реальную работу, но по сути он глупенький, так как вся его логика это обращения во внешние системы - записал в редис, сохранил че-то в бакет, заскедюлил джобу. вопрос - если я хочу покрыть данный функционал интегрейшн тестами, system under test должен быть контроллер или сервис в данном случае?
Это просто два разных теста. Тест на веб-слой и на слой сервисов.
а есть смысл тестировать их отдельно? тест на веб-слой ведь подразумевает что логика сервиса тоже вызывается
Я бы разделил на 2 - юнит тест контроллера что он правильно валидирует и готовит данные и интеграционный тест сервиса с контейнерами, что он корректно обрабатывает все кейсы - как ведет себя при недоступности редиса, че делает при отсутсвии бакета, че там у него с джобой
Ну, во-первых, это проще, тебе не нужно поднимать редис, ты проверил все правильно ли серилизуется, и т.д. и все, во-вторых, чем атомарнее тест, тем лучше.
юнит на сервис, юнит на контроллер, интеграционный на все с помощью tc
По-моему его юнит на сервис - бессмысленный, у него там только внешнее взаимодействие.
если только прокси - в целом да, но скорее зафиксировать контракты и если есть какая-то логика
плюс, там доменной логики никакой, тоже не вижу смысла юнит тесты писать
вот интересная вещь, я читал книгу Хорикова о юнит тестах, и он там говорит мол в юнит тестах моков вообще не должно быть, единственное исключение - это если логика общается с внешним сервисом, и это общение - это часть его observable behavior, тогда нужно верифицировать контракты этого общения. но с другой стороны, он там рассуждает со стороны хорошего дизайна кода, когда у нас отдельно доменная логика (юнит тесты), и код контроллеров / application services, которые глупые и просто связывают приложение с внешним миром (it).
ну есть много кейсов, например реальный ответ, вам приходит на email через неделю )
Необходимость тестировать контроллер как правило свидетельствует о проблемах архитектуры. Контроллер должен быть тонким и не иметь логики как таковой, он должен быть тупо клеем между бизнес-логикой приложения и фреймворком. Интеграционным/системным тестам это не противоречит, потому что там тестируется система целиком как неделимый ящик.
>Необходимость тестировать контроллер как правило свидетельствует о проблемах архитектуры. ну это же не правда
Автор же пишет > я хочу покрыть данный функционал интегрейшн тестами,
вопрос был как раз об интеграционных тестах, а точнее какой у них должен быть скоуп. то есть должны ли они тестировать только тот компонент, который непосредственно общается с внешними сервисами, или же проганять логику всех слоёв
"интеграционные" от слова "интеграция"
Обсуждают сегодня