Імплементація API тестування із Playwright

Щоби завершити вступний опис можливостей Playwright, поговоримо про його інструментарій для роботи з API.

За можливості роботи з API в Playwright відповідає клас APIRequestContext. Він прив’язаний до браузерного контексту, а отже, якщо в рамках вашого тестування немає спеціальних маніпуляцій із кількома контекстами, буде єдиним на весь фреймворк. Відповідно, APIRequestContext доступні cookies та storageState браузеру, всередині якого він знаходиться.

Отримати існуючий APIRequestContext можна прямо посеред скрипту чи тесту через browserContext.request або page.request. Також є можливість створити окремий ізольований контекст через apiRequest.newContext(). Це дозволяє робити запити та обробляти відповіді від API прямо в тесті:

Таким чином ми можемо створювати тести, присвячені роботі API. Будь-який HTTP-метод, представлений в APIRequestContext, приймає URL ендпоїнта та об’єкт options, в якому можна задавати супутню інформацію для запиту: заголовки, параметри URL, тіло та деякі налаштування поведінки самого Playwright у роботі із цим запитом типу таймауту чи максимальної кількості перенаправлень.

Задля кращої читабельності коду, компонувати body та options запиту краще за межами його виклику — в окремих читабельних константах. Наприклад, окремо прописати body за відповідними вимогами вашого API, а потім передати його в options разом з хедерами та іншими параметрами завдяки JSON.stringify():

Будь-який HTTP-метод з APIRequestContext повертає проміс APIResponse, з яким ми і будемо працювати. Об’єкт цього класу серед іншого має методи (так-так, саме методи, а не елементи об’єкту!):

• body та json, в яких представлено тіло відповіді у буферному вигляді чи форматовано за правилами JSON відповідно;

• headers та headersArray, в яких представлені заголовки відповіді у форматі об’єкту чи масиву відповідно;

• status та statusText, в яких представлено код чи текстове пояснення статусу запиту відповідно.

Переліченої інформації зазвичай вистачає для достатнього покриття API тестами. Щоправда, щодо самих перевірок, тобто expect’ів — Playwright має єдиний expect, що стосується безпосередньо API: await expect(response).toBeOK(). Перевірка пройде, якщо код статусу в респонсі буде 2ХХ.

Лишається можливість використовувати загальні перевірки з деталями респонсу:

Це валідний спосіб імплементації, що закриває велику кількість перевірок. Але Playwright, як доволі молоде середовище, стрімко розвивається, а бібліотека сторонніх розширень поповнюється. Вже зараз існують модулі на кшталт odottaa, які дозволяють розширити стандартний набір expect’ів виразами, що напряму стосуються тестування API. Наприклад, odottaa крім суто декларативних покращень (перевірки toBeCreated, toBeUnauthorized тощо є більш декларативними замінами перевірок статус коду на певне значення) містить і зручні перевірки типу toHaveJSON або toHaveHeaders, що суттєво спрощують роботу і підвищують якість коду.

Крім прямого тестування, API часто використовують як інструментарій в Е2Е тестах. Коли створення даних через інтерфейс користувача не є принциповим для тестування, відправити прямий запит із даними в API багатократно економить час і підвищує стабільність тестів.

Утилітарний метод для роботи із API робиться так само, як і будь-який інший (наприклад, методи для скроллу сторінки із допису про тестування UI). Єдиний нюанс полягає в тому, що ми будемо зобов’язані передавати в цей метод щонайменше об’єкт класу APIRequestContext (посеред тесту це робиться передачею page.request у виклик методу), якого він потребуватиме для роботи із запитами:

Про останню строку, яку я додав, варто обмовитись: щодо expect’ів всередині файлів POM чи утилітарних методів існує ціла дискусія. Одна сторона каже, що вирази expect за самим своїм задумом не мають з’являтися ніде крім тестів, як і підкапотна логіка не має з’являтися ніде крім фреймворку. Інші вважають, що якщо ця перевірка не стосується самого тесту, то це є непоганою можливістю додати інформативності для потенційних падінь, тобто якщо утилітарний метод із прикладу вище поверне код не із діапазону 200-299, то тест впаде саме як провал перевірки і видасть відповідний прописаний коментар. Рішення лишається за вами і хорошими практиками всередині вашої компанії.

Наостанок хотів би зазначити, що автоматизація тестування API потребує фундаментальних знань по тому, як влаштовано веб, HTTP, REST тощо, а також мануального досвіду роботи з API в тому ж Postman. Прямо як звичайна Е2Е автоматизація потребує також кваліфікації тестувальника, який зможе спроектувати мінімально достатній сьют і підібрати адекватні перевірки. Тому не нехтуйте теорією тестування та майндсетом тестувальника, перш ніж переходити до автоматизації.

Бажаю успіхів!