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

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

• Suite 1-тестирование каждой службы в изоляции
  • издевается над любыми одноранговыми службами, от использования которых зависит API restito. Другие альтернативы включают остальное-драйвера, wiremock, готовые и бетамакс.
  • тесты, сервис, который мы тестируем, и насмешки все работают в одном JVM
  • запускает сервис, который мы тестируем в Jetty

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

• одноранговые службы высмеиваются, поэтому вам не нужно выполнять сложную настройку данных. Перед каждым тестом вы просто используете restito, чтобы определить, как вы хотите, экспертных служб вели себя, как занятия в модульных тестов с Mockito.
• люкс супер быстро, как издевались услуги служат предварительно консервированные ответы в памяти. Таким образом, мы можем получить хорошее освещение без того, чтобы люкс брал возраст для запуска.
• сюита надежна и repeatable как свое изолированное в своем собственном JVM, поэтому никакая потребность потревожиться о других сюитах/людях возясь около с общей окружающей средой в то же время сюита бежит и вызывает провал тестов.

• Suite 2-полный конец до конца
  • Suite работает против полной среды, развернутой на нескольких машинах
  • API, развернутый на Tomcat в среде
  • одноранговые службы реальны "как живые" полные развертывания

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

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

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

• способность определить тестовые случаи интеграции которые осуществляют дело вариант развития событий.
  • мы используем:огурец-jvm для определения бизнес-сценариев для обоих вышеуказанных наборов. Эти сценарии представляют собой английские текстовые файлы, которые бизнес-пользователи могут понимать, а также управлять тестами.
• настройка БД с тестовыми данными перед запуском пакета.
  • мы не делаем этого для наших наборов интеграции, но в прошлом я использовал unitils С dbunit для модульных тестов и ИТ сработало неплохо.
• вызовите API REST, работающий на удаленном сервере (Tomcat)
  • мы используем:остальное-заверил, который является отличным HTTP-клиентом, специально предназначенным для тестирования REST APIs.
• Проверьте выполнение теста DB post для проверки ожидаемого результата
  • Я не могу предоставить никаких рекомендаций здесь, поскольку мы не используем библиотеки, чтобы помочь сделать это проще, мы просто делаем это вручную. Дай мне знать, если что-нибудь найдешь.
• есть отчет покрытия кода REST API, чтобы мы знали, насколько уверенно мы должны быть в сценариях, охватываемых пакетом.
  • мы не измеряем охват кода для наших интеграционных тестов, только для наших модульных тестов, поэтому я снова не могу дать никаких рекомендаций здесь.

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