Автоматизация Backend-тестирования на Java

Интенсивный курс для владеющих основами Java, сфокусированный на тестировании API и серверной логики. Вы научитесь строить надежные автотесты, работать с базами данных и интегрировать проверки в CI/CD.

1. Настройка тестового окружения и работа с фреймворками JUnit 5 и TestNG

Настройка тестового окружения и работа с фреймворками JUnit 5 и TestNG

Добро пожаловать на курс «Автоматизация Backend-тестирования на Java». Мы пропускаем основы синтаксиса языка, так как предполагается, что вы уже знакомы с Java Core, и сразу переходим к «мясу» — инструментам, которые превращают код в мощную систему проверки качества серверной части приложений.

В этой вводной статье мы подготовим фундамент: настроим окружение, разберем системы сборки и детально изучим два главных фреймворка для тестирования в экосистеме Java — JUnit 5 и TestNG.

Зачем нам специальное окружение?

Автоматизация бэкенда — это не просто написание скриптов. Это создание масштабируемой архитектуры, которая должна:

  • Управлять зависимостями (библиотеками).
  • Запускать тесты в определенном порядке.
  • Генерировать отчеты.
  • Интегрироваться с CI/CD (Continuous Integration / Continuous Delivery).
  • Для этого нам понадобятся: JDK (Java Development Kit), IDE (среда разработки) и система сборки.

    Выбор IDE и JDK

    Для этого курса мы рекомендуем использовать JDK 17 или JDK 21 (LTS версии) и среду разработки IntelliJ IDEA (Community или Ultimate). Это индустриальный стандарт, обеспечивающий наилучшую поддержку инструментов тестирования.

    Системы сборки: Maven и Gradle

    В современной Java-разработке библиотеки не скачиваются вручную в виде .jar файлов. Эту работу берут на себя системы сборки. Они управляют жизненным циклом проекта: от компиляции до запуска тестов.

    !Схематичное изображение процесса сборки проекта: от исходного кода до артефактов и отчетов.

    Apache Maven

    Maven использует файл pom.xml (Project Object Model) для конфигурации. Это декларативный подход, основанный на XML.

    Пример подключения зависимости JUnit 5 в pom.xml:

    Обратите внимание на тег <scope>test</scope>. Он говорит Maven, что эта библиотека нужна только во время компиляции и запуска тестов, но не должна попасть в итоговый продакшн-сборку приложения.

    Gradle

    Gradle — более современный и гибкий инструмент, использующий DSL (Domain Specific Language) на базе Groovy или Kotlin. Он работает быстрее Maven благодаря инкрементальной сборке.

    Тот же пример подключения JUnit 5 в build.gradle (Groovy DSL):

    > Совет: Если вы начинаете новый проект с нуля, выбирайте Gradle. Если поддерживаете существующий энтерпрайз-проект, скорее всего, там будет Maven.

    Фреймворк JUnit 5

    JUnit 5 — это стандарт де-факто в мире Java. В отличие от предыдущей 4-й версии, он модульный и состоит из трех частей:

  • JUnit Platform — фундамент для запуска тестов на JVM.
  • JUnit Jupiter — новый программный интерфейс (API) для написания тестов и расширений.
  • JUnit Vintage — движок для запуска старых тестов (JUnit 3 и 4).
  • Жизненный цикл теста

    Понимание порядка выполнения методов критически важно для настройки тестовых данных (например, подключение к базе данных перед тестами и очистка после).

    Основные аннотации JUnit 5:

    * @Test — помечает метод как тестовый. * @BeforeAll — выполняется один раз перед всеми тестами в классе (метод должен быть статическим). * @BeforeEach — выполняется перед каждым тестом. * @AfterEach — выполняется после каждого теста. * @AfterAll — выполняется один раз после всех тестов (метод должен быть статическим). * @DisplayName("Описание") — задает человекочитаемое имя теста в отчетах.

    !Визуализация жизненного цикла тестового класса в JUnit 5.

    Пример кода:

    Проверки (Assertions)

    Тест без проверок бесполезен. В JUnit 5 используется класс Assertions.

    * Assertions.assertEquals(expected, actual) — проверяет равенство. * Assertions.assertTrue(condition) — проверяет истинность условия. * Assertions.assertNotNull(object) — проверяет, что объект не null. * Assertions.assertThrows(Exception.class, () -> { ... }) — проверяет, что код выбрасывает ожидаемое исключение.

    Фреймворк TestNG

    TestNG (Test Next Generation) появился раньше JUnit 5 и вдохновил его создателей на многие фичи. Он до сих пор популярен в QA-сообществе благодаря мощной конфигурации через XML и встроенной поддержке многопоточности.

    Ключевые отличия TestNG

  • Файл testng.xml: Позволяет гибко настраивать наборы тестов (Suites), включать/исключать пакеты, классы и методы, а также передавать параметры.
  • Зависимости между тестами: Аннотация @Test(dependsOnMethods = "login") позволяет запустить тест только если прошел метод login.
  • Группировка: @Test(groups = {"smoke", "regression"}) позволяет легко запускать только нужные категории тестов.
  • Пример аннотаций TestNG (они очень похожи на JUnit, но есть отличия):

    | JUnit 5 | TestNG | | :--- | :--- | | @BeforeAll | @BeforeSuite, @BeforeTest, @BeforeClass | | @BeforeEach | @BeforeMethod | | @Test | @Test | | @AfterEach | @AfterMethod | | @AfterAll | @AfterSuite, @AfterTest, @AfterClass | | @Disabled | @Test(enabled = false) |

    Data Providers в TestNG

    Одной из киллер-фич TestNG всегда были Data Providers — способ запустить один тест с разными наборами данных.

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

    Что выбрать: JUnit 5 или TestNG?

    Этот вопрос часто вызывает холивары. Давайте посмотрим объективно:

    * JUnit 5: Современный стандарт, модульный, идеально интегрируется со Spring Boot (самый популярный фреймворк для бэкенда на Java). Если вы пишете тесты рядом с кодом разработчиков — это ваш выбор. * TestNG: Мощный инструмент для сложных сценариев E2E (End-to-End) тестирования, где важна сложная логика запуска, зависимости между тестами и параллельное выполнение «из коробки».

    В рамках этого курса мы будем делать упор на JUnit 5, так как он чаще встречается в требованиях к вакансиям SDET (Software Development Engineer in Test) и Backend QA.

    Заключение

    Мы настроили окружение и разобрались с инструментами. Теперь у вас есть понимание, как код тестов взаимодействует с системой сборки и как управлять жизненным циклом проверок.

    В следующей статье мы перейдем к практике: напишем наш первый HTTP-клиент и научимся отправлять реальные запросы к API.

    2. Основы автоматизации REST API с использованием библиотеки REST Assured

    Основы автоматизации REST API с использованием библиотеки REST Assured

    В предыдущей статье мы подготовили надежный фундамент: установили JDK, выбрали IDE и научились управлять тестами с помощью JUnit 5. Теперь пришло время заставить наш код общаться с внешним миром.

    В этой статье мы разберем REST Assured — библиотеку, которая стала индустриальным стандартом для тестирования HTTP API в экосистеме Java. Мы научимся отправлять запросы, проверять ответы и писать тесты, которые читаются как обычный английский текст.

    Почему REST Assured?

    Java имеет встроенные средства для работы с сетью (например, HttpURLConnection или новый HttpClient), но писать тесты на них — это мучение. Вам придется вручную открывать соединения, считывать байты, конвертировать их в строки и парсить JSON.

    REST Assured берет эту рутину на себя. Это DSL (Domain Specific Language), специально заточенный под тестирование REST-сервисов. Он позволяет писать код в стиле BDD (Behavior Driven Development), используя структуру Given-When-Then (Дано-Когда-Тогда).

    !Визуализация потока данных при тестировании API с использованием REST Assured.

    Подключение зависимости

    Первым делом добавим библиотеку в наш проект. Так как мы уже настроили систему сборки в прошлой лекции, просто добавьте нужный блок в конфигурационный файл.

    Для Maven (pom.xml)

    Для Gradle (build.gradle)

    Синтаксис Given-When-Then

    Вся магия REST Assured строится вокруг трех ключевых методов. Понимание этой триады — ключ к написанию чистых тестов.

  • Given (Дано) — Предусловия. Здесь мы настраиваем всё, что нужно до отправки запроса: заголовки (headers), параметры (query params), тело запроса (body), авторизацию.
  • When (Когда) — Действие. Здесь мы указываем HTTP-метод (GET, POST, PUT, DELETE) и эндпоинт (URL).
  • Then (Тогда) — Проверки. Здесь мы валидируем ответ: статус-код, содержимое тела, время ответа.
  • Ваш первый тест: GET запрос

    Давайте напишем тест, который проверяет получение информации о пользователе. Для примеров мы будем использовать публичный API https://reqres.in, который часто используют для тренировок.

    Создайте новый тестовый класс UserApiTest:

    Разберем, что здесь происходит: * .baseUri(...) — задает базовый адрес API. Это удобно, чтобы не писать полный путь в каждом тесте. * .get("/users/2") — выполняет GET-запрос на адрес https://reqres.in/api/users/2. * .statusCode(200) — это assertion (проверка). Если сервер вернет 404 или 500, тест упадет с ошибкой.

    Проверка тела ответа (Body Assertions)

    Проверять только статус-код недостаточно. Нам нужно убедиться, что сервер вернул правильные данные. REST Assured использует библиотеку Hamcrest для удобных проверок.

    Предположим, сервер возвращает такой JSON:

    Дополним наш тест проверками полей:

    Обратите внимание на синтаксис data.email. Это GPath (Groovy Path) — мощный способ навигации по JSON. Если бы у нас был массив пользователей, мы могли бы написать data[0].email.

    Отправка данных: POST запрос

    Тестирование бэкенда невозможно без создания данных. Рассмотрим отправку POST-запроса.

    Для передачи тела запроса используется метод .body(). В простых случаях можно передать JSON как строку, но в профессиональной разработке чаще используют объекты (POJO) или Map. Пока что, для простоты, используем строку.

    Важный момент: При отправке данных всегда указывайте заголовок Content-Type. Метод .contentType("application/json") делает это за вас. Без этого сервер может не понять, что вы прислали ему JSON, и вернет ошибку 400 или 415.

    Логирование и отладка

    Когда тест падает, первое, что нужно сделать — посмотреть, что именно мы отправили и что получили в ответ. REST Assured имеет встроенный механизм логирования.

    Добавьте метод .log().all() в секцию given() (чтобы видеть запрос) или then() (чтобы видеть ответ).

    В консоли вы увидите подробный вывод, похожий на cURL или вкладку Network в браузере.

    Извлечение данных (Extraction)

    Иногда нам не нужно сразу проверять значение, а нужно "вытащить" его из ответа, чтобы использовать в следующем запросе (например, получить ID созданного пользователя, чтобы потом его удалить).

    Для этого используется метод .extract().

    Оптимизация кода: RequestSpecification

    Вы наверняка заметили, что мы постоянно копируем .baseUri("https://reqres.in/api") и .contentType(...). Это нарушение принципа DRY (Don't Repeat Yourself).

    В REST Assured можно создать спецификацию запроса — шаблон, который будет применяться ко всем тестам.

    Теперь, если URL тестового стенда изменится, вам нужно будет поправить его только в одном месте — в методе setup.

    Заключение

    Сегодня мы сделали большой шаг вперед. Мы научились:

  • Подключать REST Assured.
  • Использовать синтаксис Given-When-Then.
  • Отправлять GET и POST запросы.
  • Валидировать статус-коды и JSON-тела ответов.
  • Логировать запросы для отладки.
  • Однако, ручное формирование JSON-строк (как мы делали в примере с POST) — это неудобно и чревато ошибками. В следующей статье мы разберем продвинутую тему: Сериализация и Десериализация. Мы научимся превращать Java-объекты в JSON и обратно автоматически, используя библиотеку Jackson и возможности REST Assured.

    3. Продвинутые техники: сериализация POJO, спецификации запросов и работа с авторизацией

    Продвинутые техники: сериализация POJO, спецификации запросов и работа с авторизацией

    Добро пожаловать обратно на курс «Автоматизация Backend-тестирования на Java». В прошлой статье мы научились отправлять базовые запросы и проверять ответы, используя жестко прописанные строки JSON. Это работает для простых примеров, но в реальных проектах такой подход быстро превращается в кошмар поддержки.

    Представьте, что у вас 500 тестов, использующих JSON с полем "username", и разработчики решили переименовать его в "login". Вам придется править 500 строк кода вручную. Звучит как отличный способ провести выходные на работе, не так ли? Чтобы этого избежать, мы переходим к профессиональным инструментам: POJO, Jackson и Request Specifications.

    Магия POJO и библиотека Jackson

    В мире Java данные принято хранить в объектах. POJO (Plain Old Java Object) — это простой Java-объект, который не наследуется от каких-то специфических классов и не реализует тяжеловесных интерфейсов. Он просто хранит данные.

    REST Assured умеет автоматически превращать Java-объекты в JSON (сериализация) и JSON обратно в Java-объекты (десериализация). Для этого «под капотом» используется библиотека Jackson (или Gson, если настроить).

    !Визуализация процессов преобразования данных между Java-объектами и форматом JSON.

    Подготовка POJO класса

    Допустим, мы хотим создать пользователя. Вместо склеивания строк, опишем класс:

    > Совет: Чтобы не писать геттеры, сеттеры и конструкторы вручную, используйте библиотеку Lombok. С аннотацией @Data ваш класс сократится до 5 строк.

    Сериализация (Java -> JSON)

    Теперь отправим этот объект в теле запроса. REST Assured сам поймет, что нужно сделать:

    В этот момент библиотека Jackson берет объект user, смотрит на его поля и генерирует JSON: {"name":"Morpheus", "job":"Leader"}.

    Десериализация (JSON -> Java)

    А что насчет ответа? Проверять поля через .body("name", equalTo(...)) удобно, но если полей много, лучше превратить ответ обратно в объект и проверить его средствами Java.

    Создадим класс для ответа (он может отличаться от запроса, например, наличием id и createdAt):

    Обратите внимание на аннотацию @JsonIgnoreProperties(ignoreUnknown = true). Она говорит Jackson: «Если в JSON придут поля, которых нет в классе, просто проигнорируй их, не падай с ошибкой».

    Теперь тест выглядит так:

    Спецификации запросов и ответов (Specifications)

    В предыдущих примерах мы постоянно дублировали contentType и baseUri. Принцип DRY (Don't Repeat Yourself) — это золотое правило программирования. В REST Assured для этого есть RequestSpecification.

    Создание RequestSpecification

    Мы можем вынести общие настройки в отдельный объект:

    Создание ResponseSpecification

    То же самое можно сделать для ожидаемых ответов. Например, если 90% наших тестов ожидают статус 200 и время ответа меньше 5 секунд:

    Применение в тестах

    Теперь наши тесты становятся невероятно лаконичными. Мы устанавливаем спецификации через методы .spec():

    Примечание: метод installSpecification — это условный метод-обертка, в реальном коде REST Assured спецификации часто передаются прямо в цепочку вызовов given().spec(mySpec)....

    Работа с авторизацией

    Большинство современных API закрыты от публичного доступа. Вам нужно подтвердить, кто вы. REST Assured поддерживает основные виды авторизации «из коробки».

    Basic Authentication

    Самый старый способ: логин и пароль передаются в заголовке в закодированном виде (Base64).

    Существует также Preemptive Basic Auth. Разница в том, что обычный basic() сначала делает запрос без авторизации, получает 401, и только потом отправляет креды. preemptive() отправляет их сразу.

    Bearer Token (OAuth 2.0)

    Самый популярный метод сегодня. Вы сначала получаете токен (длинную строку) через специальный запрос логина, а затем прикладываете его ко всем запросам.

    В REST Assured это делается через заголовок Authorization или специальный метод:

    !Процесс получения и использования Bearer токена для доступа к защищенному API.

    Логирование и отладка с фильтрами

    Иногда .log().all() недостаточно, или вы хотите писать логи не в консоль, а в файл отчета (например, Allure). Для этого используются фильтры.

    Фильтры позволяют перехватывать запрос и ответ, модифицировать их или сохранять информацию о них. Это мощный инструмент для построения красивых отчетов о тестировании.

    Заключение

    Сегодня мы превратили наши тесты из набора строк в стройную систему объектов. Мы изучили:

  • Сериализацию/Десериализацию: как превращать Java-классы в JSON и обратно.
  • Спецификации: как выносить общие настройки и не дублировать код.
  • Авторизацию: как стучаться в закрытые двери API.
  • Эти навыки отличают новичка от инженера по автоматизации. В следующей статье мы углубимся в архитектуру тестового фреймворка и поговорим о паттерне Page Object (да, он применим не только к UI!) и структурировании API-клиентов.

    4. Взаимодействие с базами данных через JDBC для подготовки и проверки тестовых данных

    Взаимодействие с базами данных через JDBC для подготовки и проверки тестовых данных

    Рады видеть вас снова на курсе «Автоматизация Backend-тестирования на Java». В предыдущих статьях мы научились мастерски обращаться с REST Assured: отправлять запросы, сериализовать объекты и проходить авторизацию. Казалось бы, что еще нужно?

    Представьте ситуацию: ваш автотест отправляет запрос на создание пользователя POST /users. Сервер возвращает красивый ответ 201 Created и JSON с данными пользователя. Тест проходит успешно. Но действительно ли пользователь сохранился в системе? А что, если API вернул заглушку, а в базу данных запись не попала из-за ошибки транзакции?

    Чтобы исключить такие ситуации, мы переходим от тестирования «черного ящика» к тестированию «серого ящика». Мы научимся заглядывать под капот приложения — прямо в его базу данных.

    Зачем автотестам доступ к БД?

    В автоматизации бэкенда база данных (БД) используется для трех основных целей:

  • Подготовка данных (Preconditions): Перед тестом нужно создать пользователя, которому мы будем менять пароль, или товар, который мы будем класть в корзину. Делать это через API может быть долго и ненадежно (если API создания сломан, упадет тест на смену пароля).
  • Проверка результата (Assertions): Убедиться, что после вызова API данные действительно изменились в таблице.
  • Очистка данных (Postconditions): Удалить тестовый мусор после прогона, чтобы не засорять тестовый стенд.
  • !Диаграмма показывает, как тест взаимодействует с системой: через API для действий и через БД для проверок.

    Что такое JDBC?

    JDBC (Java Database Connectivity) — это стандарт, который позволяет Java-приложению взаимодействовать с любой реляционной базой данных (PostgreSQL, MySQL, Oracle и др.), используя единый набор команд.

    Для работы нам понадобится драйвер — библиотека, которая служит переводчиком между Java и конкретной СУБД. В этом уроке мы будем использовать PostgreSQL, так как это одна из самых популярных баз данных в мире Enterprise-разработки.

    Подключение зависимости

    Добавьте драйвер PostgreSQL в ваш pom.xml (для Maven):

    Или в build.gradle (для Gradle):

    Основные этапы работы с JDBC

    Работа с базой данных в Java всегда строится по одному сценарию:

  • Открыть соединение (Connection).
  • Создать выражение (Statement).
  • Выполнить запрос (Execute).
  • Обработать результат (ResultSet).
  • Закрыть соединение.
  • 1. Открытие соединения

    Для соединения нам нужны URL базы данных, логин и пароль. URL обычно выглядит так: jdbc:postgresql://host:port/database_name.

    2. Выполнение SELECT запросов

    Чтобы прочитать данные, используется метод executeQuery. Он возвращает объект ResultSet — это таблица с результатами, по которой можно «ходить» построчно.

    Важно: Ресурсы БД (соединения, курсоры) нужно обязательно закрывать. В Java для этого используется конструкция try-with-resources.

    Метод rs.next() возвращает true, если следующая строка существует, и false, если данные закончились.

    3. Изменение данных (INSERT, UPDATE, DELETE)

    Для запросов, которые меняют данные, используется метод executeUpdate. Он возвращает количество затронутых строк (целое число).

    Безопасность и PreparedStatement

    Использовать обычный Statement и склеивать строки запроса вручную — плохая практика, даже в тестах. Это делает код уязвимым к SQL-инъекциям и сложным для чтения.

    Вместо этого используйте PreparedStatement. Он позволяет вставлять параметры в запрос безопасным способом, используя знаки вопроса ? как плейсхолдеры.

    Пример безопасного создания пользователя:

    Архитектура тестового фреймворка

    Писать JDBC-код прямо внутри тестовых методов (@Test) — грубая ошибка. Это нарушает принцип единственной ответственности и делает тесты нечитаемыми.

    Лучшая практика — вынести работу с БД в отдельный класс-помощник (Helper) или использовать паттерн DAO (Data Access Object).

    Создаем DatabaseHelper

    Интеграция в тест JUnit 5

    Теперь наш тест выглядит чисто и понятно:

    Частые ошибки при работе с JDBC в тестах

  • Забытые закрытия соединений. Если не использовать try-with-resources, соединения могут «повиснуть», и база данных перестанет отвечать, когда исчерпает лимит подключений.
  • Хардкод конфигурации. Не пишите URL и пароли прямо в коде Java. Выносите их в файлы свойств (application.properties), чтобы можно было легко переключаться между локальной базой и тестовым стендом.
  • Сложные проверки. Не пытайтесь проверить каждое поле в базе. Проверяйте критически важные данные. Логику отображения лучше проверять через API.
  • Заключение

    Сегодня мы добавили мощный инструмент в наш арсенал. JDBC позволяет нам не верить API на слово, а проверять фактическое состояние системы. Это делает тесты более надежными и позволяет находить баги, связанные с потерей или искажением данных.

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

    5. Генерация профессиональной отчетности с Allure и интеграция тестов в CI/CD

    Генерация профессиональной отчетности с Allure и интеграция тестов в CI/CD

    Поздравляем! Вы прошли долгий путь от настройки JDK до написания сложных SQL-запросов для валидации данных. Теперь у вас есть мощный набор автотестов. Но возникает вопрос: кто, кроме вас, видит результаты их работы?

    Если вы запустите тесты в IntelliJ IDEA, вы увидите зеленые галочки. Если в консоли — сухой текст логов. Но вашему менеджеру, разработчикам или заказчику это ни о чем не говорит. Им нужны красивые графики, понятная статистика и детализация ошибок.

    В этой финальной статье курса мы превратим скучные логи в красочные отчеты с помощью Allure Framework и встроим запуск тестов в автоматический конвейер CI/CD.

    Allure Framework: Стандарт качества отчетности

    Allure — это гибкий, легковесный инструмент для построения отчетов о тестировании. Он стал стандартом индустрии благодаря своей модульности и способности интегрироваться практически с любым тестовым фреймворком (JUnit, TestNG, Cucumber и др.).

    Почему именно Allure?

  • Визуализация: Строит графики прохождения тестов, распределение по времени и серьезности дефектов.
  • Иерархия: Позволяет группировать тесты по функциональности (Epic -> Feature -> Story).
  • Детализация: К каждому шагу теста можно прикрепить скриншоты, логи запросов, текстовые файлы.
  • История: Показывает тренд стабильности тестов (flaky tests) от запуска к запуску.
  • !Пример того, как выглядит главная страница отчета Allure с общей статистикой.

    Подключение Allure к проекту (Maven)

    Чтобы Allure заработал, нам нужно добавить несколько зависимостей и настроить плагин в pom.xml. Allure работает в связке с JUnit 5.

    В секцию <dependencies> добавьте:

    В секцию <build><plugins> необходимо настроить maven-surefire-plugin. Это критически важный момент: Allure использует Java Agents для перехвата событий, поэтому нам нужен aspectjweaver.

    Что делает этот скрипт:

  • Запускается при каждом пуше в ветку main.
  • Арендует виртуальную машину на Ubuntu.
  • Устанавливает Java 17.
  • Запускает тесты через Maven.
  • Генерирует отчет Allure и сохраняет историю предыдущих запусков.
  • Публикует отчет на GitHub Pages — специальный хостинг для статических сайтов.
  • В результате у вас будет постоянная ссылка (например, https://your-user.github.io/your-repo/), по которой всегда доступен актуальный отчет о состоянии проекта.

    Jenkins и GitLab CI

    В корпоративной среде часто используются Jenkins или GitLab CI.

    * Jenkins: Требует установки плагина "Allure Jenkins Plugin". В конфигурации сборки (Jenkinsfile) добавляется шаг allure(['allure-results']), который собирает XML-файлы и строит HTML-отчет внутри интерфейса Jenkins. * GitLab CI: Использует файл .gitlab-ci.yml. Отчет обычно сохраняется как "артефакт" (Job Artifacts) и доступен для скачивания или просмотра через GitLab Pages.

    Заключение курса

    Мы прошли большой путь. Вспомните, с чего мы начинали: пустой проект и непонимание, как подступиться к бэкенду. Теперь в вашем арсенале:

  • JUnit 5 для управления структурой тестов.
  • REST Assured для элегантного общения с API.
  • Jackson для сериализации сложных объектов.
  • JDBC для проверки данных напрямую в базе.
  • Allure для красивой отчетности.
  • CI/CD для автоматического запуска.
  • Автоматизация — это не просто написание кода. Это создание доверия к продукту. Ваши тесты — это страховочная сетка, которая позволяет разработчикам смело вносить изменения, зная, что если они что-то сломают, вы (а точнее, ваш автотест в CI) узнаете об этом первыми.

    Развивайтесь, изучайте новые инструменты (Docker, Kubernetes, Kafka), но помните: база, которую вы получили в этом курсе, останется актуальной еще очень долго. Удачи в автоматизации!