Как не кликать предусловия в UI-тестах: готовим полис через API и Oracle
Habr ·
О чём статья. UI-тест часто проверяет одну кнопку, а подготовка данных занимает больше места, чем сама проверка. Покажем, как мы решаем это в автотестах страхования жизни: человека создаем через API, полис оформляем в браузере, нужный статус выставляем процедурой Oracle, а результат проверяем в интерфейсе. Что вы получите. Рабочую схему подготовки данных с реальным кодом и пятью приемами, которые можно перенести на свой проект. Кому интересно. Автоматизаторам UI-тестов в системах, где у сущности длинный жизненный цикл: договоры, заявки, заказы. Допустим, нам нужно проверить кнопку отмены полиса. Открыть договор, нажать кнопку отмены, проверить результат. Звучит как небольшой UI-тест. Но сначала договор должен существовать. У него должны быть страхователь, нужный способ подписания, даты и подходящий статус. Если проверяем поведение действующего полиса, только что сохраненная форма нам еще не подходит. Подготовка начинает занимать больше места, чем само действие, ради которого написан тест. Разберем, как эта задача решена в проекте автотестов команды инвестиционного и накопительного страхования жизни в АльфаСтрахование-Жизнь: человека создаем через API, полис оформляем в браузере, нужное состояние подготавливаем через Oracle. Затем возвращаемся в интерфейс и проверяем, что получили именно тот договор, который ожидали. Проект написан на Java 21 и собирается Maven. Тесты запускает JUnit 5, а Spring Framework связывает клиенты, сервисы и фабрики данных. Для запросов к API используем REST Assured, для работы с браузером — Selenide, для доступа к Oracle — Spring JDBC. Проверки пишем с AssertJ, ожидание асинхронных результатов — с Awaitility, а шаги и результаты собираем в отчеты Allure. Читать далее