API-автотесты проверяют бизнес-логику приложения без пользовательского интерфейса. Они выполняются быстрее UI-тестов, проще локализуют ошибки и хорошо подходят для CI/CD. Рассмотрим подход на Java, JUnit 5 и REST Assured. Автотест отправляет HTTP-запрос к сервису и проверяет код, заголовки и тело ответа. Статуса 200 недостаточно: ответ может содержать неправильные данные. Хороший API-тест проверяет: • HTTP-код и Content-Type; • обязательные поля и их значения; • структуру JSON; • бизнес-правила; • фактические изменения в системе. Пример: given() .baseUri("https://test-api.example.ru") .pathParam("id", 15) .when() .get("/api/users/{id}") .then() .statusCode(200) .body("id", equalTo(15)) .body("status", equalTo("ACTIVE")); Архитектура проекта Не стоит хранить всю логику запросов внутри тестовых методов. Удобнее разделить проект на слои: src/test/java ├── api — работа с endpoint ├── config — URL и общие настройки ├── dto — модели запросов и ответов ├── tests — бизнес-сценарии └── utils — генераторы данных DTO описывает тело запроса и ответа, а API-клиент скрывает технические детали вызова endpoint. Благодаря этому тест остаётся коротким и читаемым. Сам тест должен читаться как сценарий: @Test void shouldCreateUser() { var request = new CreateUserRequest( "Иван Петров", uniqueEmail(), "StrongPassword123!" );

var user = userApi.createUser(request) .then() .statusCode(201) .extract() .as(UserResponse.class);

assertAll( () -> assertNotNull(user.id()), () -> assertEquals(request.name(), user.name()), () -> assertEquals("ACTIVE", user.status()) ); } Тестовые данные Не используйте постоянные email, номера заказов и другие уникальные значения. Повторный запуск может завершиться конфликтом. Например, email можно формировать через UUID.randomUUID(). Созданные данные желательно удалять после теста. Иначе стенд заполняется мусором, а тесты становятся зависимыми от предыдущих запусков. Негативные сценарии Позитивной проверки недостаточно. Нужно проверять: • отсутствие обязательного поля; • неправильный формат; • граничные и слишком длинные значения; • несуществующий идентификатор; • запрос без авторизации; • недостаточные права; • неправильный Content-Type; • повторное создание объекта. userApi.getUser(999999999L) .then() .statusCode(404) .body("error.code", equalTo("USER_NOT_FOUND")); Контракт API JSON Schema позволяет обнаружить отсутствие обязательного поля, изменение типа данных или несовместимое изменение структуры ответа. .body(matchesJsonSchemaInClasspath( "schemas/user-schema.json" )); Цепочки запросов Наибольшую ценность часто дают сквозные бизнес-сценарии: Создать заказ → получить заказ → оплатить → проверить статус PAID Такой тест проверяет не отдельный endpoint, а реальную работу процесса. Внешние сервисы Для платёжных, SMS- и других внешних сервисов используйте моки, например WireMock. Они позволяют имитировать успех, ошибку 500, задержку и тайм-аут. Логирование Не нужно выводить в консоль все запросы и ответы. Удобнее включать логирование только при падении: RestAssured .enableLoggingOfRequestAndResponseIfValidationFails(); Пароли, токены, cookie и персональные данные в логах необходимо маскировать. Частые ошибки: • проверять только HTTP-код; • связывать тесты между собой; • хранить токены в коде; • использовать постоянные данные; • применять Thread.sleep; • не очищать данные; • запускать тесты только вручную. Для асинхронных процессов вместо Thread.sleep используйте повторные проверки с общим тайм-аутом. Надёжный API-автотест должен подготовить данные, отправить запрос, проверить код, структуру и значения ответа, подтвердить бизнес-результат и удалить созданные данные. Хорошая архитектура, независимые сценарии и понятное логирование превращают API-тесты в стабильный инструмент контроля качества.