Фреймворк для тестування UI. Як його налаштувати на Java

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Всім привіт! Мене звати Олександр, час від часу я ділюся своїм досвідом роботи з Java з технічною спільнотою. В попередній раз я писав про фреймворк для тестування API сервісів на Java і в мене виникла ідея написати про загальніший фреймворк, який буде додатково містити частини для тестування UI, можливість взаємодіяти з базою даних та логування з репортом.

До об’єкта тестування я висував наступні вимоги:

• система має мати UI та API інтерфейси;
• система має мати взаємодією з базою даних;
• система має бути опенсорс та безкоштовною;
• розгортання системи локально має бути максимально простим.

Як об’єкт тестування я вибрав KanBoard, оскільки це програмне забезпечення задовольняє всім моїм вимогам. Kanboard — це опенсорс програмне забезпечення, яке дозволяє створювати проєктні дашборди із завданнями.

Розгортається система локально однією командою docker compose up з папки, де знаходиться docker-compose.yml. У випадку фреймворку цей файл знаходиться у root папці. Я не буду описувати, як встановити docker, цю інформацію можна отримати за посиланням. Якщо не змінювати налаштування у docker-compose.yml файлі, то інтерфейс буде доступний за лінкою http://127.0.0.1/login, юзер має креди admin/admin.

Так само як і у попередньому випадку фреймворк написаний на Java-стеці технологій. Використано Maven, Lombok, TestNG, Rest Assured, Cucumber, JDBI, Allure та Selenide. По архітекторі фреймворк складається з трьох шарів (layers), а саме: рівень page objects; рівень definitions, assertions та hooks; і на кінець рівень features. Також у складі фреймворку знаходяться три допоміжні компоненти, а саме: Config, Data generation та Shared data компонентів.

Для прикладу був автоматизований тест, що юзер може створити завдання. В тесті юзер та проєкт створюється через API у прекондішенах, а також видаляються у посткондішенах. Також через API видаляється завдання, яке було створене через UI. Створення спеціальних сутностей під тест, а потім видалення цих сутностей збільшує ізоляцію тестів та підвищує надійність тестів.

Config компонент складається з двох класів EnvProperties та PropertiesReader. Компонент бере дані з параметрів командної строки maven. Якщо такий параметр не заданий, тоді компонент зчитує його з env.properties файлу. Зберігати чутливу інформацію в репозиторії вважається за погану ідею, тому краще такі параметри передавати через командну строку.

Data generation складається з одного класу DataProvider і використовує Faker бібліотеку. Компонент генерує об’єкти з випадковими даними, де це можливо.

Shared data компонент складається з двох класів SharedDataSingelton та SharedData. Однією з проблем використання cucumber є питання, як передавати дані між різними кроками, які своєю чергою можуть бути у різних класах. Для вирішення цієї задачі можна використати Thread Singleton, який дає нам гарантію, що для кожного потоку буде створено лише один об’єкт-контейнер, через який можна буде передати дані.

KanBoard має не типове API, але яке теж побудоване на HTTP-протоколі. По суті використовується тільки один метод POST і в тілі методу передається той метод, який ми хочемо виконати, наприклад getAllProjects. Більше про API можна дізнатися за посиланням. Було вирішено використати модифікований підхід з дженеріками з попередньої статті. Суть полягає в тому, щоб використовувати один і той самий метод і типізовувати його вже в тестах.

Об’єктна репрезентація запиту і відповідь має складну дворівневу структуру. Перший рівень складається з RequestWrapper та Response wrapper, які крім самої відповіді ще містять HTTP метадату, таку як headers. Другий рівень складається з APIRequestMode, APIResponseArrayModel та APIResponseEntityModel, які крім відповіді ще містять метадату від KanBoard API, таку як jsonrpc.

DB component потрібен для роботи з базою даних і отримання результатів у об’єктній репрезентації. DB component складається з TaskDBController, DBController та DBConnection. DBConnection побудований з використанням Thred Singelton патерну, так само як і Shared data. Не рекомендується використовувати DB component для прекондішенів, тому що це може спричинити проблеми з даними (невідповідність даних).

UI component потрібен для взаємодії з WEB UI частиною. Складається з page objects. Для деяких елементів немає задовільних локаторів, тому використано обгортки пошуку по тексту. В реальних проєктах рекомендовано використати такий підхід як тимчасовий і створювати ріквести на створення тестових id, наприклад [@testId = ’taskLabel’]. Саме тестові id дозволять мати ізоляцію від девелопмент-процесу і при цьому отримати надійний спосіб пошуку елементу.

Всі компоненти використовуються у definitions, assertions та hooks, а не напряму. Це дозволяє розділити логіку і зменшити дублювання коду.

Для запуску тестів створено TestCasesRunnerForTasksFeatures, в якому вказується місцезнаходження feature файлів та місцезнаходження кроків. Також доданий метод scenarios, який дозволяє запускати тести у паралель. Кількість потоків задається опцією threadCount у секції maven surefire plugin у pom.xml файлі. Для прогону тестів в intellij idea необхідно встановити cucumber plugin та модифікувати Run configuration з двома опціями Main class: io.cucumber.core.cli.Main, Glue: steps.hooks steps.definitions steps.assertions.

Для запуску тестів через командну строку необхідно створити regression.xml з посиланням на TestCasesRunnerForTasksFeatures та заповнити його ім’я опцією suiteXmlFiles у секції maven surefire plugin у pom.xml файлі. Після цього тести будуть запускатися за командою mvn clean test.

Для репорту використано Allure. Для підключення потрібно модифікувати секції maven surefire plugin у pom.xml файлі з опціями argLine та allure.results.directory у секції maven surefire plugin у pom.xml файлі.

Також необхідно встановити та прописати у path allure cli. Після прогону тестів буде створено папку target/allure-results з результатами тестів. Командую allure serve target/allure-results репорт буде розгорнута на локальній машині. Для додавання скріншотів використано ReportHooks.

Для логування використано вбудовані функції Rest Assured, а також slf4j-simple на рівні definitions, assertions та hooks.

Повний код фреймворку можна знайти за посиланням.