Модульное и интеграционное тестирование - неотъемлемая часть вашей повседневной жизни как разработчика. Однако для новичков Spring Boot написание содержательных тестов для своих приложений оказывается проблемой:
Помимо включения и управления версией Spring Test, этот Spring Boot Starter включает и управляет версиями следующих библиотек:
В большинстве случаев ваши модульные тесты не нуждаются в какой-либо конкретной функции Spring Boot или Spring Test, поскольку они будут полагаться исключительно на JUnit и Mockito.
С помощью модульных тестов вы изолированно тестируете, например, свои *Serviceклассы и имитируете каждого сотрудника тестируемого класса:
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import java.math.BigDecimal;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;
@ExtendWith(MockitoExtension.class) // register the Mockito extension
public class PricingServiceTest {
@Mock // // Instruct Mockito to mock this object
private ProductVerifier mockedProductVerifier;
@Test
public void shouldReturnCheapPriceWhenProductIsInStockOfCompetitor() {
when(mockedProductVerifier.isCurrentlyInStockOfCompetitor("AirPods"))
.thenReturn(true); //Specify what boolean value to return
PricingService cut = new PricingService(mockedProductVerifier);
assertEquals(new BigDecimal("99.99"), cut.calculatePrice("AirPods"));
}
}
Как видно из раздела importтестового класса выше, Spring вообще не включается. Следовательно, вы можете применять методы и знания, полученные из модульного тестирования любого другого приложения Java.
Вот почему важно изучить основы JUnit 4/5 и Mockito, чтобы максимально использовать возможности модульного тестирования.
Для некоторых частей вашего приложения модульное тестирование не принесет особой пользы. Хорошими примерами для этого являются уровень персистентности или тестирование HTTP-клиента. Тестируя такие части вашего приложения, вы в конечном итоге почти копируете свою реализацию, поскольку вам приходится имитировать много взаимодействий с другими классами.
Лучшим подходом здесь является работа с нарезанным контекстом Spring, который можно легко автоматически настроить с помощью аннотаций теста Spring Boot.
Цель этих тестов - изолированно протестировать определенную часть вашего приложения без запуска всего приложения. Это сокращает как время выполнения теста, так и потребность в обширной настройке теста.
Как назвать такие тесты? На мой взгляд, они не попадают на 100% в категорию модульных или интеграционных тестов. Некоторые разработчики называют их модульными тестами, потому что они тестируют, например, один контроллер изолированно. Другие разработчики относят их к интеграционным тестам, поскольку в них задействована поддержка Spring. Как бы вы их ни называли, убедитесь, что у вас есть общее понимание, по крайней мере, в вашей команде.
Spring Boot предлагает много аннотаций, позволяющих проверить различные части вашего приложения в отдельности: @JsonTest, @WebMvcTest, @DataMongoTest, @JdbcTestи т.д.
Все они автоматически настраивают фрагменты Spring TestContextи включают только компоненты Spring, относящиеся к тестированию определенной части вашего приложения. Я посвятил целую статью представлению наиболее распространенных из этих аннотаций и объяснению их использования.
Две наиболее важные аннотации (сначала изучите их):
Вы всегда можете расширить контекст автонастройки для своего теста, явно импортировав компоненты с помощью @Importили определив дополнительные компоненты Spring Beans, используя @TestConfiguration:
@WebMvcTest(PublicController.class)
class PublicControllerTest {
@Autowired
private MockMvc mockMvc;
@Autowired
private MeterRegistry meterRegistry;
@MockBean
private UserService userService;
@TestConfiguration
static class TestConfig {
@Bean
public MeterRegistry meterRegistry() {
return new SimpleMeterRegistry();
}
}
}
Вы можете найти дополнительные методы устранения потенциальных исключений NoSuchBeanDefinitionException, скоторыми вы можете столкнуться при таких тестах, в этом сообщении в блоге.
Важно следить за импортом, особенно за @Testаннотацией:
// JUnit 4
import org.junit.Test;
// JUnit Jupiter (part of JUnit 5)
import org.junit.jupiter.api.Test;
Другими индикаторами для JUnit 4 являются: @RunWith, @Rule, @ClassRule, @Before, @BeforeClass, @After, @AfterClass.
С помощью JUnit 5 vintage-engineваш набор тестов может содержать как тесты JUnit 3/4, так и JUnit Jupiter, но каждый тестовый класс может использовать только одну конкретную версию JUnit. Рассмотрите возможность миграции существующих тестов, чтобы использовать различные новые функции JUnit Jupiter (параметризованные тесты, распараллеливание, модель расширения и т. д.). Вы можете постепенно мигрировать свой набор тестов, так как вы можете запускать тесты JUnit 3/4 рядом с тестами JUnit 5.
Документация JUnit включает советы по миграции JUnit 4, а также имеются инструменты (JUnit Pioneer или эта функция IntelliJ) для автоматической миграции тестов (например, импорт или проверки утверждений).
После того, как вы мигрировали свой набор тестов на JUnit 5, важно исключить любое появление устаревшей версии JUnit. Не все в вашей команде могут постоянно обращать пристальное внимание на импорт библиотек тестирования. Чтобы избежать случайного смешивания разных версий JUnit, исключение их из вашего проекта помогает всегда выбирать правильный импорт:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
Кроме Spring Boot Starter Test другие зависимости тестования также могут включать более старые версии JUnit:
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>junit-jupiter</artifactId>
<version>${testcontainers.version}</version>
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
</dependency>
Чтобы избежать (случайного) включения зависимостей JUnit 4 в будущем, вы можете использовать Maven Enforcer Plugin и определить его как запрещенную зависимость. Это приведет к сбою сборки, как только кто-то включит новую тестовую зависимость, которая транзитивно потянет JUnit 4.
Обратите внимание, что, начиная с Spring Boot 2.4.0, зависимость Spring Boot Starter Test больше не включает vintage-engineфайл по умолчанию.
@SpringBootTestбудет заполнять весь контекст приложения для теста. При использовании этой аннотации важно понимать атрибут webEnvironment. Без указания этого атрибута такие тесты не будут запускать встроенный контейнер сервлетов (например, Tomcat) и вместо этого будут использовать имитацию среды сервлетов. Следовательно, ваше приложение не будет доступно через локальный порт.
Вы можете переопределить это поведение, указав либо, DEFINE_PORTлибо RANDOM_PORT:
Для интеграционных тестов, которые запускают встроенный контейнер сервлетов, вы можете затем внедрить порт своего приложения и получить к нему доступ извне, используя TestRestTemplateили WebTestClient:
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class ApplicationTests {
@LocalServerPort
private Integer port;
@Autowired
private TestRestTemplate testRestTemplate;
@Test
void accessApplication() {
System.out.println(port);
}
}
Поскольку TestContextSpring фреймворка будет заполнять весь контекст приложения, вы должны убедиться, что присутствуют все зависимые компоненты инфраструктуры (например, база данных, очереди сообщений и т. д.).
Здесь в игру вступают Testcontainers. Testcontainers будет управлять жизненным циклом любого Docker контейнера для вашего теста:
@Testcontainers
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class ApplicationIT {
@Container
public static PostgreSQLContainer postgreSQLContainer = new PostgreSQLContainer()
.withPassword("inmemory")
.withUsername("inmemory");
@DynamicPropertySource
static void postgresqlProperties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url", postgreSQLContainer::getJdbcUrl);
registry.add("spring.datasource.password", postgreSQLContainer::getPassword);
registry.add("spring.datasource.username", postgreSQLContainer::getUsername);
}
@Test
public void contextLoads() {
}
}
Для ознакомления с Testcontainers рассмотрите следующие ресурсы:
Кроме того, TestContextSpring фреймворк имеет удобную функцию кеширования и повторного использования, а также уже запущенный контекст. Это может помочь сократить время сборки и значительно улучшить циклы обратной связи.
Вы также можете выполнить тесты E2E для развернутой версии приложения, например, в среде devили stagingпрежде чем приступить к развертыванию в рабочей среде.
Для приложений, которые используют рендеринг на стороне сервера (например, Thymeleaf) или автономной системы, когда серверная часть Spring Boot обслуживает интерфейс, вы можете использовать @SpringBootTest дляэтих тестов.
Как только вам нужно взаимодействовать с браузером, Selenium обычно является выбором по умолчанию. Если вы какое-то время работали с Selenium, вы сможете обнаружить, что снова и снова реализуете одни и те же вспомогательные функции. Для лучшего взаимодействия с разработчиками и уменьшения головной боли при написании тестов, предполагающих взаимодействие с браузером, рассмотрите вариант Selenide. Selenide - это абстракция поверх низкоуровневого API Selenium для написания стабильных и кратких тестов браузера.
Следующий тест демонстрирует, как получить доступ и протестировать общедоступную страницу приложения Spring Boot с помощью Selenide:
@Testcontainers
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class BookStoreTestcontainersWT {
@LocalServerPort
private Integer port;
@Test
public void shouldDisplayBook() {
Configuration.timeout = 2000;
Configuration.baseUrl = "http://localhost:" + port;
open("/book-store");
$(By.id("all-books")).shouldNot(Condition.exist);
$(By.id("fetch-books")).click();
$(By.id("all-books")).shouldBe(Condition.visible);
}
}
Вы можете найти больше информации о Selenide в этом сообщении в блоге.
Для компонентов инфраструктуры, которые необходимо запустить для тестов E2E, Testcontainers играет большую роль. Если вам нужно запустить несколько Docker контейнеров, вам пригодится модуль Docker Compose из Testcontainers :
public static DockerComposeContainer<?> environment =
new DockerComposeContainer<>(new File("docker-compose.yml"))
.withExposedService("database_1", 5432, Wait.forListeningPort())
.withExposedService("keycloak_1", 8080, Wait.forHttp("/auth").forStatusCode(200)
.withStartupTimeout(Duration.ofSeconds(30)))
.withExposedService("sqs_1", 9324, Wait.forListeningPort());
Кроме того, аннотации Spring Boot test упрощают написание тестов для различных частей вашего приложения. Вы получите специально созданный Spring TestContextтолько с соответствующими Spring beans.
Чтобы познакомиться с модульными и интеграционными тестами для ваших проектов Spring Boot, рекомендуются следующие шаги:
Кроме того, активность сообщества на Stack Overflow для таких тегов, как spring-test, spring-boot-testили spring-test-mvc, довольно хороша, и есть большая вероятность, что вы получите помощь. Я также часто отвечаю на вопросы, связанные с тестированием, на Stack Overflow.
Удачного модульного и интеграционного тестирования с помощью Spring Boot,
Источник статьи: https://habr.com/ru/post/561520/
- С чего начать мои усилия по тестированию?
- Как Spring Boot может помочь мне в написании эффективных тестов?
- Какие библиотеки мне использовать?
Модульное тестирование с помощью Spring Boot
Модульные тесты составляют основу вашей стратегии тестирования. Каждый проект Spring Boot, который вы запускаете с помощью Spring Initializr, имеет прочную основу для написания модульных тестов. Настраивать практически нечего, так как Spring Boot Starter Test включает в себя все необходимые строительные блоки.Помимо включения и управления версией Spring Test, этот Spring Boot Starter включает и управляет версиями следующих библиотек:
- JUnit 4/5
- Mockito
- Библиотеки проверки утверждений, такие как AssertJ, Hamcrest, JsonPath и т. Д.
В большинстве случаев ваши модульные тесты не нуждаются в какой-либо конкретной функции Spring Boot или Spring Test, поскольку они будут полагаться исключительно на JUnit и Mockito.
С помощью модульных тестов вы изолированно тестируете, например, свои *Serviceклассы и имитируете каждого сотрудника тестируемого класса:
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import java.math.BigDecimal;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;
@ExtendWith(MockitoExtension.class) // register the Mockito extension
public class PricingServiceTest {
@Mock // // Instruct Mockito to mock this object
private ProductVerifier mockedProductVerifier;
@Test
public void shouldReturnCheapPriceWhenProductIsInStockOfCompetitor() {
when(mockedProductVerifier.isCurrentlyInStockOfCompetitor("AirPods"))
.thenReturn(true); //Specify what boolean value to return
PricingService cut = new PricingService(mockedProductVerifier);
assertEquals(new BigDecimal("99.99"), cut.calculatePrice("AirPods"));
}
}
Как видно из раздела importтестового класса выше, Spring вообще не включается. Следовательно, вы можете применять методы и знания, полученные из модульного тестирования любого другого приложения Java.
Вот почему важно изучить основы JUnit 4/5 и Mockito, чтобы максимально использовать возможности модульного тестирования.
Для некоторых частей вашего приложения модульное тестирование не принесет особой пользы. Хорошими примерами для этого являются уровень персистентности или тестирование HTTP-клиента. Тестируя такие части вашего приложения, вы в конечном итоге почти копируете свою реализацию, поскольку вам приходится имитировать много взаимодействий с другими классами.
Лучшим подходом здесь является работа с нарезанным контекстом Spring, который можно легко автоматически настроить с помощью аннотаций теста Spring Boot.
Тесты фрагментов Spring Context
В дополнение к традиционным модульным тестам вы можете писать тесты с помощью Spring Boot, которые нацелены на определенные части (фрагменты) вашего приложения. TestContext Spring фреймворка вместе с Spring Boot адаптирует Spring контекст с достаточным количеством компонентов для конкретного теста.Цель этих тестов - изолированно протестировать определенную часть вашего приложения без запуска всего приложения. Это сокращает как время выполнения теста, так и потребность в обширной настройке теста.
Как назвать такие тесты? На мой взгляд, они не попадают на 100% в категорию модульных или интеграционных тестов. Некоторые разработчики называют их модульными тестами, потому что они тестируют, например, один контроллер изолированно. Другие разработчики относят их к интеграционным тестам, поскольку в них задействована поддержка Spring. Как бы вы их ни называли, убедитесь, что у вас есть общее понимание, по крайней мере, в вашей команде.
Spring Boot предлагает много аннотаций, позволяющих проверить различные части вашего приложения в отдельности: @JsonTest, @WebMvcTest, @DataMongoTest, @JdbcTestи т.д.
Все они автоматически настраивают фрагменты Spring TestContextи включают только компоненты Spring, относящиеся к тестированию определенной части вашего приложения. Я посвятил целую статью представлению наиболее распространенных из этих аннотаций и объяснению их использования.
Две наиболее важные аннотации (сначала изучите их):
- @WebMvcTestдля эффективного тестирования вашего веб-слоя с помощью MockMvc
- @DataJpaTestдля эффективного тестирования вашего уровня персистентности
- @JsonTest для проверки сериализации и десериализации JSON
- @RestClientTest чтобы протестировать RestTemplate
- и @DataMongoTest для тестирования кода, связанного с MongoDB
Вы всегда можете расширить контекст автонастройки для своего теста, явно импортировав компоненты с помощью @Importили определив дополнительные компоненты Spring Beans, используя @TestConfiguration:
@WebMvcTest(PublicController.class)
class PublicControllerTest {
@Autowired
private MockMvc mockMvc;
@Autowired
private MeterRegistry meterRegistry;
@MockBean
private UserService userService;
@TestConfiguration
static class TestConfig {
@Bean
public MeterRegistry meterRegistry() {
return new SimpleMeterRegistry();
}
}
}
Вы можете найти дополнительные методы устранения потенциальных исключений NoSuchBeanDefinitionException, скоторыми вы можете столкнуться при таких тестах, в этом сообщении в блоге.
Ловушка JUnit 4 и JUnit 5
Одна большая ловушка, с которой я довольно часто сталкиваюсь, отвечая на вопросы на Stack Overflow, - это сочетание JUnit 4 и JUnit 5 (JUnit Jupiter, если быть более конкретным) в одном тесте. Использование API разных версий JUnit в одном тестовом классе может привести к неожиданным результатам и сбоям.Важно следить за импортом, особенно за @Testаннотацией:
// JUnit 4
import org.junit.Test;
// JUnit Jupiter (part of JUnit 5)
import org.junit.jupiter.api.Test;
Другими индикаторами для JUnit 4 являются: @RunWith, @Rule, @ClassRule, @Before, @BeforeClass, @After, @AfterClass.
С помощью JUnit 5 vintage-engineваш набор тестов может содержать как тесты JUnit 3/4, так и JUnit Jupiter, но каждый тестовый класс может использовать только одну конкретную версию JUnit. Рассмотрите возможность миграции существующих тестов, чтобы использовать различные новые функции JUnit Jupiter (параметризованные тесты, распараллеливание, модель расширения и т. д.). Вы можете постепенно мигрировать свой набор тестов, так как вы можете запускать тесты JUnit 3/4 рядом с тестами JUnit 5.
Документация JUnit включает советы по миграции JUnit 4, а также имеются инструменты (JUnit Pioneer или эта функция IntelliJ) для автоматической миграции тестов (например, импорт или проверки утверждений).
После того, как вы мигрировали свой набор тестов на JUnit 5, важно исключить любое появление устаревшей версии JUnit. Не все в вашей команде могут постоянно обращать пристальное внимание на импорт библиотек тестирования. Чтобы избежать случайного смешивания разных версий JUnit, исключение их из вашего проекта помогает всегда выбирать правильный импорт:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
Кроме Spring Boot Starter Test другие зависимости тестования также могут включать более старые версии JUnit:
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>junit-jupiter</artifactId>
<version>${testcontainers.version}</version>
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
</dependency>
Чтобы избежать (случайного) включения зависимостей JUnit 4 в будущем, вы можете использовать Maven Enforcer Plugin и определить его как запрещенную зависимость. Это приведет к сбою сборки, как только кто-то включит новую тестовую зависимость, которая транзитивно потянет JUnit 4.
Обратите внимание, что, начиная с Spring Boot 2.4.0, зависимость Spring Boot Starter Test больше не включает vintage-engineфайл по умолчанию.
Интеграционные тесты с Spring Boot: @SpringBootTest
С помощью интеграционных тестов вы обычно тестируете несколько компонентов вашего приложения в комбинации. Большая часть времени вы будете использовать @SpringBootTestаннотацию для этой цели и доступ к приложению с внешней стороны с помощью либо WebTestClientили TestRestTemplate.@SpringBootTestбудет заполнять весь контекст приложения для теста. При использовании этой аннотации важно понимать атрибут webEnvironment. Без указания этого атрибута такие тесты не будут запускать встроенный контейнер сервлетов (например, Tomcat) и вместо этого будут использовать имитацию среды сервлетов. Следовательно, ваше приложение не будет доступно через локальный порт.
Вы можете переопределить это поведение, указав либо, DEFINE_PORTлибо RANDOM_PORT:
Для интеграционных тестов, которые запускают встроенный контейнер сервлетов, вы можете затем внедрить порт своего приложения и получить к нему доступ извне, используя TestRestTemplateили WebTestClient:
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class ApplicationTests {
@LocalServerPort
private Integer port;
@Autowired
private TestRestTemplate testRestTemplate;
@Test
void accessApplication() {
System.out.println(port);
}
}
Поскольку TestContextSpring фреймворка будет заполнять весь контекст приложения, вы должны убедиться, что присутствуют все зависимые компоненты инфраструктуры (например, база данных, очереди сообщений и т. д.).
Здесь в игру вступают Testcontainers. Testcontainers будет управлять жизненным циклом любого Docker контейнера для вашего теста:
@Testcontainers
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class ApplicationIT {
@Container
public static PostgreSQLContainer postgreSQLContainer = new PostgreSQLContainer()
.withPassword("inmemory")
.withUsername("inmemory");
@DynamicPropertySource
static void postgresqlProperties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url", postgreSQLContainer::getJdbcUrl);
registry.add("spring.datasource.password", postgreSQLContainer::getPassword);
registry.add("spring.datasource.username", postgreSQLContainer::getUsername);
}
@Test
public void contextLoads() {
}
}
Для ознакомления с Testcontainers рассмотрите следующие ресурсы:
- Написание тестов интеграции Spring Boot с помощью Testcontainers
- Тестирование приложений Spring Boot с помощью Kotlin и Testcontainers
- Стратегии инициализации с помощью тестовых контейнеров для интеграционных тестов
Кроме того, TestContextSpring фреймворк имеет удобную функцию кеширования и повторного использования, а также уже запущенный контекст. Это может помочь сократить время сборки и значительно улучшить циклы обратной связи.
Сквозные тесты с Spring Boot
Целью сквозных (E2E) тестов является проверка системы с точки зрения пользователя. Сюда входят тесты для основных сценариев работы пользователя (например, размещение заказа или создание нового клиента). По сравнению с интеграционными тестами такие тесты обычно включают пользовательский интерфейс (если он есть).Вы также можете выполнить тесты E2E для развернутой версии приложения, например, в среде devили stagingпрежде чем приступить к развертыванию в рабочей среде.
Для приложений, которые используют рендеринг на стороне сервера (например, Thymeleaf) или автономной системы, когда серверная часть Spring Boot обслуживает интерфейс, вы можете использовать @SpringBootTest дляэтих тестов.
Как только вам нужно взаимодействовать с браузером, Selenium обычно является выбором по умолчанию. Если вы какое-то время работали с Selenium, вы сможете обнаружить, что снова и снова реализуете одни и те же вспомогательные функции. Для лучшего взаимодействия с разработчиками и уменьшения головной боли при написании тестов, предполагающих взаимодействие с браузером, рассмотрите вариант Selenide. Selenide - это абстракция поверх низкоуровневого API Selenium для написания стабильных и кратких тестов браузера.
Следующий тест демонстрирует, как получить доступ и протестировать общедоступную страницу приложения Spring Boot с помощью Selenide:
@Testcontainers
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class BookStoreTestcontainersWT {
@LocalServerPort
private Integer port;
@Test
public void shouldDisplayBook() {
Configuration.timeout = 2000;
Configuration.baseUrl = "http://localhost:" + port;
open("/book-store");
$(By.id("all-books")).shouldNot(Condition.exist);
$(By.id("fetch-books")).click();
$(By.id("all-books")).shouldBe(Condition.visible);
}
}
Вы можете найти больше информации о Selenide в этом сообщении в блоге.
Для компонентов инфраструктуры, которые необходимо запустить для тестов E2E, Testcontainers играет большую роль. Если вам нужно запустить несколько Docker контейнеров, вам пригодится модуль Docker Compose из Testcontainers :
public static DockerComposeContainer<?> environment =
new DockerComposeContainer<>(new File("docker-compose.yml"))
.withExposedService("database_1", 5432, Wait.forListeningPort())
.withExposedService("keycloak_1", 8080, Wait.forHttp("/auth").forStatusCode(200)
.withStartupTimeout(Duration.ofSeconds(30)))
.withExposedService("sqs_1", 9324, Wait.forListeningPort());
Резюме
Spring Boot предлагает отличную поддержку как для модульного, так и для интеграционного тестирования. Это делает тестирование первоклассным гражданином, поскольку каждый проект Spring Boot включает в себя Spring Boot Starter Test. Этот стартер подготовит ваш базовый набор инструментов для тестирования с необходимыми библиотеками тестирования.Кроме того, аннотации Spring Boot test упрощают написание тестов для различных частей вашего приложения. Вы получите специально созданный Spring TestContextтолько с соответствующими Spring beans.
Чтобы познакомиться с модульными и интеграционными тестами для ваших проектов Spring Boot, рекомендуются следующие шаги:
- Изучите и поймите основы JUnit и Mockito
- Избегайте ловушки JUnit 4 и JUnit 5.
- Ознакомьтесь с различными аннотациями тестирования Spring Boot, которые автоматически настраивают фрагменты контекста.
- WireMock, Testcontainers и Selenide помогут в ваших задачах по интеграционному и сквозному тестированию.
- Узнайте, как Spring TestContext Caching может помочь сократить общее время выполнения вашего набора тестов.
Кроме того, активность сообщества на Stack Overflow для таких тегов, как spring-test, spring-boot-testили spring-test-mvc, довольно хороша, и есть большая вероятность, что вы получите помощь. Я также часто отвечаю на вопросы, связанные с тестированием, на Stack Overflow.
Удачного модульного и интеграционного тестирования с помощью Spring Boot,
Источник статьи: https://habr.com/ru/post/561520/