Интеграционный тест API REST с охватом кода - программирование
Подтвердить что ты не робот

Интеграционный тест API REST с охватом кода

Мы создали API REST, который предоставляет множество бизнес-сервисов - бизнес-сервис может вызывать другие платформы/служебные службы для выполнения операций чтения и записи баз данных, для выполнения авторизации службы и т.д.

Мы использовали эти службы в качестве файлов WAR в Tomcat.

Мы хотим протестировать всю эту установку с помощью набора тестов интеграции, который мы также хотели бы рассматривать как набор тестов регрессии.

Что было бы хорошим подходом для проведения тестирования интеграции на этом и любых инструментов, которые могут ускорить разработку пакета? Вот несколько требований, которые, по нашему мнению, нам необходимо решить:

  • Возможность определения тестовых примеров интеграции, которые выполняют бизнес-сценарии.
  • Настройте базу данных с тестовыми данными до запуска пакета.
  • Вызов API REST, работающего на удаленном сервере (Tomcat)
  • Подтвердить выполнение тестового теста DB для проверки ожидаемого результата
  • Получите отчет о покрытии кода API REST, чтобы мы знали, насколько мы уверенны в сценариях, охватываемых пакетом.
4b9b3361

ОТВЕТЫ

Ответ 1

В моей работе мы недавно собрали пару тестовых наборов для тестирования некоторых API RESTful, которые мы построили. Как и ваши сервисы, наши могут ссылаться на другие API RESTful, от которых они зависят. Мы разделили его на два набора.

  • Suite 1 - тестирование каждой службы изолированно
    • Извлекает любые сервисы peer API, которые зависят от использования restito. Другие альтернативы включают rest-driver, wiremock, pre-canned и betamax.
    • Тестирование, сервис, который мы тестируем, и все издевательства запускаются в одной JVM
    • Запуск службы, которую мы тестируем в Jetty

Я бы определенно рекомендовал это сделать. Это сработало очень хорошо для нас. Основные преимущества:

  • Службы одноранговой сети высмеиваются, поэтому вам не нужно выполнять какую-либо сложную настройку данных. Перед каждым тестом вы просто используете restito для определения того, как вы хотите, чтобы службы-сверстники вели себя так же, как и с классами в модульных тестах с Mockito.
  • Сюита очень быстро, так как издевательские службы обслуживают предварительно запрограммированные ответы в памяти. Таким образом, мы можем получить хорошее покрытие без набора, требующего возраста для запуска.
  • Набор надежный и повторяемый, поскольку он изолирован в нем собственной JVM, поэтому не нужно беспокоиться о других пакетах/людях, сбрасывающих с общей средой, в то же время пакет работает и приводит к сбоям тестирования.
  • Suite 2 - полный конец до конца
    • Suite работает против полной среды, развернутой на нескольких машинах.
    • API, развернутый на Tomcat в среде
    • Службы сверстников являются реальными "живыми" полноценными развертываниями.

Этот набор требует от нас делать данные, настроенные в одноранговых службах, что означает, что тесты обычно требуют больше времени для написания. Насколько это возможно, мы используем клиенты REST для создания данных, созданных в одноранговых службах.

Тесты в этом пакете обычно занимают больше времени, поэтому мы помещаем большую часть нашего охвата в Suite 1. Это говорит о том, что в этом пакете по-прежнему остается четкое значение, так как наши макеты в Suite 1 не могут вести себя как настоящие сервисы,

Что касается ваших очков, вот что мы делаем:

  • Возможность определять тестовые примеры интеграции, которые выполняют бизнес-сценарии.
    • Мы используем cucumber-jvm для определения бизнес-сценариев для обоих вышеперечисленных наборов. Эти сценарии представляют собой текстовые текстовые файлы английского языка, которые бизнес-пользователи могут понять, а также вести тесты.
  • Настройте базу данных с тестовыми данными перед запуском пакета.
    • Мы не делаем этого для наших пакетов интеграции, но в прошлом я использовал unitils с dbunit для модульных тестов, и это работал довольно хорошо.
  • Вызвать API REST, запущенный на удаленном сервере (Tomcat)
    • Мы используем rest-assured, который является отличным HTTP-клиентом, специально предназначенным для тестирования API REST.
  • Подтвердить выполнение тестового теста базы данных для проверки ожидаемого результата
    • Здесь я не могу дать никаких рекомендаций, так как мы не используем какие-либо библиотеки, чтобы помочь сделать это проще, мы просто делаем это вручную. Дайте мне знать, если вы найдете что-нибудь.
  • Получите отчет о покрытии кода API REST, чтобы мы знали, насколько мы уверенны в сценариях, охватываемых пакетом.
    • Мы не измеряем покрытие кода для наших интеграционных тестов, только для наших модульных тестов, поэтому снова я не могу предоставить никаких рекомендаций здесь.

Держите глаза очищенными на techblog, поскольку в будущем их может быть больше.

Ответ 2

Вы также можете проверить инструмент с именем Arquillian, сначала его немного сложно настроить, но обеспечивает полное время выполнения для (т.е. запускает собственный экземпляр контейнера и развертывает ваше приложение вместе с тестами) и предоставляет расширения, которые решают ваши проблемы (вызывая конечные точки REST, подавая базы данных, сравнивая результаты после тестов).

Расширение Jacoco генерирует отчеты о покрытии, которые могут быть позже отображены, то есть с помощью инструмента Sonar.

Я использовал его для относительно небольшого проекта JEE6, и, как только мне удалось его настроить, я был вполне доволен тем, как он работает.