Проектирование фундамента: настройка стека Java, Maven и RestAssured
Проектирование фундамента: настройка стека Java, Maven и RestAssured
Представьте, что банк запускает новую версию системы управления потоком клиентов (aeqs-api-test). Разработчики обновили логику выдачи талонов, и вам нужно убедиться, что API работает корректно. В Postman вы нажимаете кнопку «Send» и проверяете статус 200. Завтра выйдет новый патч — и вы снова нажмете эту кнопку. Через месяц таких эндпоинтов станет пятьдесят, а релизы начнут выходить каждый день. Ручная проверка превратится в бесконечный цикл копирования токенов и пролистывания JSON-ответов глазами.
Чтобы разорвать этот цикл, тестировщики переносят логику проверок в код. Код не устает, выполняется за секунды и запускается автоматически при каждом обновлении системы. В этой статье мы заложим фундамент для такого автотестирования.
Архитектура тестового стека
Переход от Postman к коду означает, что теперь вы сами собираете инструмент для тестирования из готовых блоков. Для работы с API на Java индустриальным стандартом стал следующий набор технологий:
- Java — базовый язык программирования, на котором мы будем писать логику.
- Maven — система сборки. Это ваш «завхоз». Вместо того чтобы вручную скачивать библиотеки из интернета, вы пишете список нужных инструментов в специальном файле, а Maven сам их находит, скачивает и подключает к проекту.
- JUnit — фреймворк для запуска тестов. Именно он понимает, какие куски кода являются тестами, запускает их по очереди и выдает зеленый или красный свет по итогу.
- RestAssured — библиотека для отправки HTTP-запросов и проверки ответов. Это наш программный аналог Postman.
Сборка фундамента: Maven
Любой современный Java-проект начинается с Maven (или его аналога Gradle). Сердце Maven-проекта — файл pom.xml (Project Object Model). В нем мы указываем зависимости (dependencies) — те самые библиотеки, которые нужны нам для работы.
Чтобы научить наш пустой Java-проект делать HTTP-запросы и запускать тесты, добавим в pom.xml две зависимости: RestAssured и JUnit.
<dependencies>
<!-- Библиотека для работы с API -->
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>5.3.0</version>
<scope>test</scope>
</dependency>
<!-- Фреймворк для запуска тестов -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.9.2</version>
<scope>test</scope>
</dependency>
</dependencies>
Тег <scope>test</scope> говорит Maven, что эти библиотеки нужны только для тестирования и не должны попасть в итоговую сборку самого приложения (если бы мы писали само приложение, а не только тесты к нему).
Первый тест: от Postman к RestAssured
Давайте автоматизируем простую проверку: убедимся, что сервис управления очередью aeqs-api-test жив и возвращает статус 200 на запрос получения списка услуг.
В Postman вы бы выбрали метод GET, вставили URL http://aeqs-api-test.local/api/v1/services и нажали Send. RestAssured использует подход BDD (Behavior-Driven Development), который делит любой тест на три логических блока, читающихся как обычное предложение на английском: Given (Дано), When (Когда), Then (Тогда).
Вот как выглядит наш первый автотест на Java:
import static io.restassured.RestAssured.*;
import org.junit.jupiter.api.Test;
public class QueueServicesTest {
@Test
public void checkServicesEndpointIsAlive() {
given()
.baseUri("http://aeqs-api-test.local") // Подготовка (URL, заголовки, параметры)
.when()
.get("/api/v1/services") // Действие (HTTP-метод и эндпоинт)
.then()
.statusCode(200); // Проверка (ожидаемый результат)
}
}
Разберем анатомию этого кода:
- Аннотация
@Testперед методом — это сигнал для JUnit. Увидев ее, JUnit понимает: «Ага, этот метод нужно запустить как независимый тест». - В блоке
given()мы собираем запрос. Это аналог вкладок Params, Authorization и Headers в Postman. Здесь мы указываем базовый адрес системы. - В блоке
when()происходит само действие — отправка запроса. Это аналог кнопки Send. Мы указываем конкретный метод (GET) и путь (path). - В блоке
then()мы валидируем ответ. Это аналог вкладки Tests в Postman. Если сервер вернет 404 или 500, RestAssured выбросит ошибку, и JUnit пометит тест как упавший (красный).
Использование given().when().then() делает код самодокументируемым. Любой член команды, даже не зная глубоко Java, сможет прочитать тест и понять, что именно он проверяет.
Мы заложили фундамент: проект собирается, запросы отправляются, а статусы ответов проверяются. Но в реальной жизни проверки редко ограничиваются статус-кодом. Банковская система возвращает сложные JSON-структуры с талонами, номерами окон и временем ожидания. О том, как элегантно извлекать эти данные и превращать их в Java-объекты для глубоких проверок, мы поговорим на следующем этапе.