Тестирование приложения java-джерси

Question

У меня есть java / jersey api, который вызывается из внешнего интерфейса.Мне нужно написать тесты для кода Java.Как написан код: 1. Вызов api выполняет метод ресурса, он вызывает отдельный метод, который получает данные из базы данных и возвращает метод ресурса.Затем он возвращает клиенту javax.ws.rs.core.Response.

Это будет мой первый раз при написании тестов, поэтому, пожалуйста, ответьте, учитывая, что я ничего не знаю.Какой лучший способ начать здесь?И какие виды тестов я должен написать.Модульные тесты - вот к чему я стремлюсь.

Сейчас я провел здесь много исследований и склоняюсь к использованию JUnit + Mockito для этого.Но как мне проверить данные в объекте Response?

А как мне проверить другой файл, который получает данные из БД?Я узнал, что DBUnit может это сделать, но нужно ли это мне?

Еще одна структура, с которой я столкнулся, была «Успокоиться»Нужно ли включать это тоже?Или можно сделать то же самое с JUnit / Mockito?

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

Answer 1

Я не думаю, что есть лучший способ сделать это, то, что вам нужно проверить, часто субъективно и зависит от контекста.

Однако вы можете структурировать свой код таким образом, чтобы наиболее важные из них были легко протестированы, а то, что осталось (интеграция), можно сделать позже / с помощью различных инструментов.

Я предлагаю следовать принципам гексагональной архитектуры . Идея состоит в том, чтобы держать в центре вашего приложения и без каких-либо зависимостей (импорт ...) к любой среде ( jaxrs , jpa и т. Д.) Все бизнес-правила. Эти правила могут быть легко разработаны с помощью TDD. Тогда у вас будут очень короткие тесты. Может потребоваться использовать Mockito для имитации реализации интерфейсов SPI.

Во второй раз вы можете использовать это «ядро», подключая адаптеры к внешнему миру (HTTP, базы данных, AMQP и т. Д.), Используя API и реализуя интерфейсы SPI.

Если вы хотите протестировать эти адаптеры, вы выходите из области действия unit-tests и пишете интеграционные тесты . Интеграция с фреймворком, протоколом, чем угодно. В такого рода тестах могут использоваться самые разнообразные инструменты: от макета, связанного с фреймворком (например, тестовая структура Джерси ), база данных в памяти (например, H2 ) до полнофункционального промежуточного программного обеспечения. Например, используя такие инструменты, как testcontainers .

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

Надеюсь, это поможет вам!