Как облегчить жизнь программисту при написании тестов

Наверняка, многие из вас работали или хотя бы слышали о том, что есть разработчики, которые работают над проектом в одиночку. Ну как в одиночку… Есть скрам, аналитик, продакт, еще кто-то вплоть до директора, а вот программист один, даже тестировщика нет. В этом случае оптимальным видом тестирования, на мой взгляд, является интеграционное тестирование с  использованием тест-контейнеров.

Привет, Хабр! Меня зовут Николай Пискунов — ведущий разработчик в подразделении Big Data. И сегодня в блоге beeline cloud поговорим о Spring boot и интеграционном тестировании. Расскажу, как упростить жизнь при написании тестов.

Погружаемся в детали…

Допустим, что у нас есть контроллер со стандартными CRU-операциями:

@RestController @RequiredArgsConstructor @RequestMapping(value = "/api/v1") @FieldDefaults(level = AccessLevel.PRIVATE, makeFinal = true) public class FooController {      FooService fooService;      @PostMapping    public ResponseEntity<FooDto> create(@Valid @RequestBody FooDtoRequest request) {        return ResponseEntity.ok(fooService.create(request));    }      @GetMapping    public ResponseEntity<PagedFooDto> readAll(@RequestParam(value = "page", defaultValue = "0") Integer page,                                           @RequestParam(value = "pageSize", defaultValue = "15") Integer pageSize) {          return ResponseEntity.ok(fooService.getFooDtoFromDB(page, pageSize));    }      @GetMapping(value = "/{uuid}")    public ResponseEntity<FooDto> readOne(@PathVariable UUID uuid) {        return ResponseEntity.ok(fooService.getOneFooDtoFromDB(uuid));    }      @PutMapping(value = "/{uuid}")    public ResponseEntity<FooDto> update(@Valid @RequestBody FooDtoRequest request, @PathVariable UUID uuid) {        FooDto response = fooService.update(request, uuid);        return ResponseEntity.ok(response);    }      @DeleteMapping(value = "/{uuid}")    public ResponseEntity<Map<String, String>> delete(@PathVariable UUID uuid) {        fooService.delete(uuid);        return ResponseEntity.ok(Map.of("status", "deleted"));    } } 

 И требуемые нам объекты выглядят так (для простоты пусть поля в этих объектах будут одинаковые).

 Request:

public record FooDtoRequest(    UUID id,      @NotBlank(message = "field must not be blank")    String fooFieldOne,      @NotBlank(message = "field must not be blank")    String fooFieldTwo ) {    @Builder    public FooDtoRequest {} } 

Response:

public record FooDto (    UUID id,    String fooFieldOne,    String fooFieldTwo ) {    @Builder    public FooDto {} } 

За контроллером расположен стандартный сервис-класс, который выполняет CRUD-операции с записями в базе данных. Эндпоинты, реализованные в этом контроллере, мы и будем покрывать интеграционными тестами.

 В проектах я чаще всего использую maven. Подключаем зависимости, необходимые для проведения тестирования:

<dependency>    <groupId>junit</groupId>    <artifactId>junit</artifactId>    <scope>test</scope> </dependency> <dependency>    <groupId>org.testcontainers</groupId>    <artifactId>junit-jupiter</artifactId>    <version>${testcontainers.version}</version>    <scope>test</scope> </dependency> <dependency>    <groupId>org.testcontainers</groupId>    <artifactId>spock</artifactId>    <version>${testcontainers.version}</version>    <scope>test</scope> </dependency> <dependency>    <groupId>org.testcontainers</groupId>    <artifactId>postgresql</artifactId>    <version>${testcontainers.version}</version>    <scope>test</scope> </dependency> <dependency>    <groupId>io.rest-assured</groupId>    <artifactId>rest-assured</artifactId>    <version>${rest-assured.version}</version>    <scope>test</scope> </dependency> <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>

Тест-класс необходимо пометить аннотациями:

@Slf4j @DirtiesContext @Testcontainers @AutoConfigureMockMvc @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class FooTests { … }

В схеме примера нам потребуется тестовая БД, я использую Postgresql.

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

@Container public static final JdbcDatabaseContainer<?> postgreSQLContainer =        new PostgisContainerProvider()            .newInstance("15-3.4")            .withDatabaseName("tests-db")            .withUsername("sa")                .withPassword("sa");

После того как контейнер проинициализируется, иногда требуется выполнить какой-либо SQL скрипт. Например, заполнить данными созданные таблицы. Для этого достаточно разместить файл с SQL командами в папке resources и добавить “.withInitScript(«test.sql»)”:

@Container public static final JdbcDatabaseContainer<?> postgreSQLContainer =        new PostgisContainerProvider()            .newInstance("15-3.4")            .withDatabaseName("tests-db")            .withUsername("sa")            .withPassword("sa")            .withInitScript("test.sql"); 

Testcontainers так же позволяют нам динамически управлять характеристиками приложения. В нашем примере динамически будут меняться данные для подключения к базе данных:

@DynamicPropertySource private static void datasourceConfig(DynamicPropertyRegistry registry) {    registry.add("spring.datasource.url", postgreSQLContainer::getJdbcUrl);    registry.add("spring.datasource.username", postgreSQLContainer::getUsername);    registry.add("spring.datasource.password", postgreSQLContainer::getPassword); } 

На этом этапе мы готовы писать тесты, а сам класс должен выглядеть примерно так:

@Slf4j @DirtiesContext @Testcontainers @AutoConfigureMockMvc @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class FooTests {      @LocalServerPort    Integer port;      @Container    public static final JdbcDatabaseContainer<?> postgreSQLContainer =        new PostgisContainerProvider()                .newInstance("15-3.4")                .withDatabaseName("tests-db")                .withUsername("sa")                .withPassword("sa");      @DynamicPropertySource    private static void datasourceConfig(DynamicPropertyRegistry registry) {        registry.add("spring.datasource.url", postgreSQLContainer::getJdbcUrl);        registry.add("spring.datasource.username", postgreSQLContainer::getUsername);        registry.add("spring.datasource.password", postgreSQLContainer::getPassword);    }      @BeforeEach    void setUp() {        RestAssured.baseURI = "http://localhost:" + port;    } } 

К примеру, у нас есть список тест-кейсов — они должны корректно отработать, чтобы  считалось, что приложение готово увидеть свет.

Предлагаю начать с положительных тестов и добавить запись в наш сервис. Для этого используем метод given() из библиотеки RestAssured:

import static io.restassured.RestAssured.given;

И добавим первый тест:

@Test void goodTestCases() {    FooDtoRequest request = FooDtoRequest.builder()        .fooFieldOne("fooFieldOne")        .fooFieldTwo("fooFieldTwo")        .build();      given()        .contentType(ContentType.JSON)        .body(b) // задаем тело запроса        .when()        .post("/api/v1") // выполняем запрос        .then()        .statusCode(200) // проверяем статус ответа        // проверяем корректность заполнения полей ответа        .body("fooFieldOne", equalTo(request.fooFieldOne()))        .body("fooFieldTwo", equalTo(requestb.fooFieldTwo()))            .log(); } 

Теперь нужно получить запись после создания. Для этого после запроса на создание добавим запрос на получение. 

Получение происходит по урлу “/api/v1/{uuid}”. Где uuid — это идентификатор только что созданной сущности, которая возвращается на POST-запрос. Чтобы его получить, нужно слегка изменить первый запрос:

FooDto response = given()        .contentType(ContentType.JSON)        .body(request)        .when()        .post("/api/v1")        .as(FooDto.class);

Теперь это объект, из которого можно получить id и ничто не мешает выполнить GET-запрос:

given()        .contentType(ContentType.JSON)        .pathParam("uuid", response.id())        .when()        .get("/api/v1/{uuid}")        .then()    .statusCode(200)    // проверяем корректность заполнения полей ответа    .body("fooFieldOne", equalTo(request.fooFieldOne()))        .body("fooFieldTwo", equalTo(request.fooFieldTwo()));

 Затем обновим объект:

request = FooDtoRequest.builder()        .fooFieldOne("NEWFieldOne")        .fooFieldTwo("NEWFieldTwo")        .build();   given()        .contentType(ContentType.JSON)        .body(request)        .pathParam("uuid", response.id())        .when()        .put("/api/v1/{uuid}")        .then()        .statusCode(200)    // проверяем корректность заполнения полей ответа    .body("fooFieldOne", equalTo(request.fooFieldOne()))        .body("fooFieldTwo", equalTo(request.fooFieldTwo()));

И удалим:

given()        .contentType(ContentType.JSON)        .pathParam("uuid", response.id())        .when()        .delete("/api/v1/{uuid}")        .then()        .statusCode(200);

Итак, один из положительных сценариев тестирования мы провели. Улучшить его можно, например, проверками данных непосредственно в БД.

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

beeline cloud— secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.