Spring boot: следует ли проверять проверку при тестировании уровня контроллера

Я работаю над проектом, в котором хочу иметь достойную тестовую инфраструктуру. Я использую весеннюю загрузку, что упрощает тестирование отдельных слоев проекта: например

Если я хочу протестировать уровень контроллера, я буду имитировать (с помощью mockito) служебные зависимости контроллера и проверять, будет ли вызываться правильный метод обслуживания для данного http-запроса, и будет ли возвращен ожидаемый статус http. Если я хочу протестировать сервисный уровень, я буду издеваться над зависимостями репозитория и бизнес-логики. И так далее.

В моем проекте я использую весенние валидаторы, чтобы проверить, правильно ли передано тело запроса (с использованием метода @InitBinder я добавляю свои пользовательские валидаторы в WebDataBinder, а с использованием аннотации @Valid эти валидаторы вызываются для проанализированного тело запроса).

Итак, мой вопрос: является ли хорошей практикой имитировать валидаторы и тестировать только логику контроллера (валидаторы будут тестироваться в контексте уровня валидатора)? Я просто не уверен, что лучше, и нормально ли тестировать валидаторы вместе с контроллерами?


person haykart    schedule 14.11.2017    source источник


Ответы (1)


Имитация не всегда лучший вариант, когда вы тестируете логику контроллера, логику проверки и особенно бизнес-логику. Я бы не рекомендовал издеваться над любым из них.

Вы можете использовать различные фреймворки для тестирования:

  1. Логика контроллера — RestAssured или MockMvc
  2. Бизнес-логика — простые тесты JUnit в SpringBootTest и SpringRunner
  3. Логика проверки — простые тесты JUnit в SpringBootTest и SpringRunner

Для дальнейшего чтения:
RestAssured: http://rest-assured.io/
Тест валидатора Spring: Написание тестов JUnit для реализации Spring Validator

person Yogi    schedule 14.11.2017
comment
Лично я считаю, что тестирование слоев проекта по отдельности является хорошей практикой, и мокирование помогает достичь этого (если у вас объектно-ориентированный дизайн, который правильно соблюдает принцип проектирования Dependency Inversion). Я согласен с 3 пунктами, которые вы упомянули. Но для тестирования уровня контроллера, отделенного от уровня проверки (как вы предложили в пунктах 1 и 3), вам нужно будет имитировать валидаторы, которые используются контроллером, и это был мой вопрос: это хорошая практика - имитировать валидаторы для тестирования уровень контроллера отдельно? - person haykart; 14.11.2017
comment
Мой ответ: не издеваться над валидаторами на уровне контроллера, если вы используете RestAssured. - person Yogi; 14.11.2017
comment
Если я правильно понял из документации RestAssured, этот метод будет тестировать не только уровень контроллера, но и всю логику конечной точки, поэтому он станет производственным тестом, а не просто модульным тестом для уровня. Конечно, у меня будут отдельные производственные тесты, и, возможно, я буду использовать RestAssured для этой цели, но перед этим я хотел бы протестировать уровень контроллера независимо от другого уровня. Если я вас правильно понял, вы предлагаете даже не издеваться над сервисами, с чем я не согласен. Но я думаю, это его личные предпочтения. В любом случае, спасибо за ответ. - person haykart; 14.11.2017
comment
Привет, хайкарт, как тебе удалось это решить? Я столкнулся с той же проблемой. Я тестирую свой веб-уровень приложения с помощью @WebMvcTest. Я не хочу, чтобы он подключался к базе данных, потому что это не модульное тестирование. - person Marcos; 15.12.2020