Очень часто все наши тесты JUnit выполняются автоматически как часть сборки CI с использованием Maven. Однако на это часто уходит много времени.
Поэтому мы часто хотим фильтровать наши тесты и выполнять либо модульные тесты, либо интеграционные тесты, либо и то, и другое на разных этапах процесса сборки.
В этом руководстве мы рассмотрим несколько методов фильтрации для тестовых случаев с JUnit 5 . В следующих разделах мы также рассмотрим различные механизмы фильтрации до JUnit 5.
JUnit и TestNG, несомненно, являются двумя самыми популярными средами модульного тестирования в экосистеме Java. Хотя JUnit вдохновляет сам TestNG, он предоставляет свои отличительные черты и, в отличие от JUnit, работает для функциональных и более высоких уровней тестирования.
В этом посте мы обсудим и сравним эти фреймворки, рассмотрев их особенности и распространенные варианты использования .
При написании тестовых случаев часто нам нужно выполнить некоторые инструкции по настройке или инициализации перед выполнением тестов, а также некоторую очистку после завершения тестов. Давайте оценим их в обеих рамках.
При тестировании производительности с помощью JMeter мы можем столкнуться с веб-сервисами, защищенными протоколом HTTP Basic Authentication.
В этом руководстве мы увидим, как настроить Apache JMeter для предоставления необходимых учетных данных во время теста.
Базовая аутентификация — это простейший метод контроля доступа, который мы можем использовать для защиты веб-ресурса. Он состоит из HTTP-заголовка, отправленного клиентом:
Apache Camel — это мощная среда интеграции с открытым исходным кодом, реализующая ряд известных шаблонов интеграции предприятия .
В этом руководстве мы научимся писать надежные автономные модульные тесты для наших маршрутов Camel .
Во-первых, мы начнем с создания базового приложения Camel с использованием Spring Boot . Затем мы рассмотрим, как мы можем использовать API поддержки тестирования Camel Spring с JUnit 5 для тестирования нашего приложения.
В этом руководстве мы проиллюстрируем различные варианты использования стандартных статических фиктивных методов Mockito API.
Как и в других статьях, посвященных фреймворку Mockito (например , Mockito Verify или Mockito When/Then ), класс MyList , показанный ниже, будет использоваться в качестве соавтора, который будет имитироваться в тестовых примерах:
public class MyList extends AbstractList<String> {
@Override
public String get(int index) {
return null;
}
@Override
public int size() {
return 1;
}
}
В этой статье рассматривается Spring Boot TestRestTemplate . Его можно рассматривать как продолжение Руководства по RestTemplate , которое мы настоятельно рекомендуем прочитать, прежде чем сосредоточиться на TestRestTemplate . TestRestTemplate можно рассматривать как привлекательную альтернативу RestTemplate .
Чтобы использовать TestRestTemplate , вам необходимо иметь соответствующую зависимость, например:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-test</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
Мы часто сталкиваемся с приложениями, которые выполняют какой-то веб-запрос. Когда дело доходит до тестирования этого поведения, у нас есть несколько вариантов с приложениями Spring.
** В этом кратком руководстве мы рассмотрим всего пару способов имитации таких вызовов, выполняемых только через** RestTemplate .
Мы начнем с тестирования с Mockito, популярной библиотеки имитации. Затем мы будем использовать Spring Test, который предоставляет нам механизм для создания фиктивного сервера для определения взаимодействия с сервером.
МокитоВ этом кратком руководстве мы рассмотрим некоторые расширенные сценарии с поддержкой REST. Мы изучали REST-assured ранее в руководстве Руководство по REST-assured .
Чтобы продолжить, мы рассмотрим примеры, показывающие, как устанавливать заголовки, файлы cookie и параметры для наших запросов.
Настройка такая же, как и в предыдущей статье, поэтому давайте углубимся в наши примеры.
В этом руководстве мы обсудим, как использовать внедрение зависимостей для вставки макетов Mockito в Spring Beans для модульного тестирования.
В реальных приложениях, где компоненты часто зависят от доступа к внешним системам, важно обеспечить надлежащую изоляцию тестов, чтобы мы могли сосредоточиться на тестировании функциональности данного модуля без необходимости задействовать всю иерархию классов для каждого теста.
Внедрение макета — это чистый способ ввести такую изоляцию.