Автоматизація тестування API, або Чому я вирішив обрати Postman

Буквально кілька тижнів тому я прийняв вольове рішення написати API тести для нашої дошки адміністратора новинного порталу. Для вирішення цього завдання існує маса інструментів та методів, реалізованих на різних мовах.

Але для початку кілька слів про себе. На даний момент я займаю посаду QA Automation в компанії Genesis Media. Ми розробляємо сайти новин і редакційні системи для 4 країн Африки, а також Філіппін і Казахстану. І ось, в перерві між потоковими завданнями, я вирішив, що не так вже й погано автоматизувати наш API. Враховуючи той факт, що до мене цього ніхто не робив і доведеться все починати з чистого аркуша, у мене були розв'язані руки.

Які я розглядав варіанти

У голову мені прийшло три найбільш простих рішення. Перше — втоматизировать все в тестовому фреймворку для Selenium з використанням Java (я ж автоматизатор все таки ;)). Друге - це використовувати новомодний Cypress . Або третє — все-таки використовувати вузьконаправлений інструмент за типом Postman або SoupUI .

Перший варіант мені подобався менше всього через складність впровадження. На даний момент все налаштовано таким чином, що запуск вимагає цілої купи параметрів CI або локально. До того ж поєднувати UI тести (end-to-end) з API (integration) — не найкраща з моїх ідей. Ну і не буду лукавити зі своїми читачами — я давно вже не тестував API з використанням Java і просто не міг згадати всіх підводних каменів або хоча б бібліотек.

На користь Cypress говорило те, що я ось тільки почав його використовувати і тримав руку на пульсі. Та й до того ж з його використанням вже була написана частина UI-тестів для цієї адмінки. А хто використовував цей інструмент - знає, як сильно в ньому рекомендують використовувати API додатка для всього, що не є метою тестування в конкретному тесті. Отже, у мене вже була частина готових API запитів. Треба визнати, що Cypress зробив все, щоб робота з запитами не доставляла вам зайвого головного болю.

Третій варіант виглядав найбільш простим та чого вже там — більш бажаним. З Postman, імовірно, працювали всі, хто хоч якось пов'язаний з веб-розробкою, і в зайвих представлень не потребує. Я був не винятком, але те, чого мені жодного разу не вдавалося, оскільки це не просто протестувати конкретні endpoints, але і написати тести на його основі.

Для аргументованого рішення у виборі інструменту потрібно щось трохи більше, ніж просто бажання (глибоке зітхання розчарування). Для порівняння я вирішив написати пару простих запитів, логін і створення статті, в Cypress і Postman c однаковими перевірками. Це могло дати можливість оцінити складність в написанні запитів, додавання тестів до них і в результаті зрозуміти, який з варіантів буде зручніше підтримувати надалі. Ну і не варто випускати з уваги те, що я зможу запустити ці самі тести і банально подивитися, що виконується швидше.

Cypress

Я почав з того, що вже було готове - запитів в Cypress. Залишалося лише прибрати зайве з коду і додати просту перевірку статусу. Отже, ось що у мене вийшло для запиту реєстрації і створення завдання:

Two basic API tests in Cypress

На скріншоті вище ми можемо спостерігати запит на логін і створення завдання з мінімальним набором необхідних полів (назви в json схемою такі дивні через NDA і відсутності фантазії). Після кожного запиту ми порівнюємо отриманий статус код з очікуваним. Все досить просто навіть для мене - людини, що не так давно почав своє знайомство з JavaScript. Cypress дозволяє виносити загальні змінні в файл cypress.json, що робить підтримку і параметризацію тестів досить зручною. Але що ж щодо швидкості виконання?

Test results in Cypress runner

На цьому скріншоті ви можете побачити Cypress runner і час, яке пішло на виконання двох тестів - 1.87 секунди . Не такий вже й поганий результат. Але проблема криється в тому, що вся інфраструктура вже піднята. Якщо ж запустити тести з консолі, так як вони і повинні запускатися в CI/CD, то тільки на запуск самого Cypress йде більше десяти секунд. А це вже не так приємно. І нехай у нас буде трохи більше запитів, ніж зараз, але піднімати настільки чималий клієнт для такої простої задачі не здається вже настільки доцільним.

Отже, ми маємо наступні плюси Cypress:

Простий синтаксис при написанні тестів, у якому зможе за кілька днів розібратися навіть новачок.
Готова інфраструктура з можливістю простого параметризированного запуску.
Наявність інтерактивного ранера, де можна подивитися всі помилки прямо в консолі.

А що ж з мінусів:

Дуже довгий запуск.
Необхідність писати код запитів (нехай він і не складний).

Не так вже й багато.

Postman

Тепер давайте подивимося, як піде процес з Postman. І от вам відразу ж скріншот запиту:

Request view in Postman

Тут все досить банально, особливо для тих, хто вже використовував Postman в цілях тестування API. Просто записуємо всі параметри та їх значення в таблицю, додаємо до них опису за необхідності. Виносимо url в змінну оточення і з її допомогою прописуємо endpoint. А у вкладці «Tests» вибираємо сніппет для перевірки статусу відповіді. Єдине, з чим можуть бути проблеми у початківців, — це передати токен з відповіді логіна в наступні запити. Але це вирішується знову таки через запис змінної оточення. А код для цього можна взяти в сніппеті з промовистою назвою «Set environment variable».

Окей, запускаю тести в якості колекції з самого Postman і отримую наступну картину:

API test run in runner Postman

Результат — кілька менше двох секунд на два запиту. Приблизно той же результат (насправді він повинен був бути краще, але інтернет в новому офісі на момент написання статті не залишив мені шансів). Але ось що ми побачимо, якщо запустимо все це з консолі?

Для вирішення цього завдання існує npm пакет Newman . Що ж, встановлюємо, читаємо мінімальну документацію і запускаємо. Для цього експортуємо нашу колекцію із запитами і тестами в них, а також не забуваємо експортувати оточення, як звичайне, так і глобальне, якщо його використовуємо. Команда для запуску проста:

newman run имя_файла_коллекции -e имя_файла_окружения -g имя_файла_глобального_окружения

Newman run results in CLI

В результаті бачимо ідентичні результати для окремих запусків, але різниця в тому, що для старту знадобилося менше секунди.

І після давайте швидко поговоримо про плюси і мінуси (а то мені ще висновки писати, а ви і так вже мабуть втомилися все це читати).

Плюси:

Інструмент, з яким знайомі багато, і він дуже простий у зверненні.
Запити пишуться швидко, і для цього не потрібно ніякого коду, а відтак ними зможуть скористатися всі без винятку.
Украй швидкий старт тестів.
Вбудована можливість шерінгу колекцій всередині робочої команди для платних аккаунтів.
Генерація документації по створеним запитів і збережених відповідей.

Мінуси:

При написанні параметрів запиту у формі form-data як і раніше зустрічаються прикрі неприємності, на кшталт неможливості передачі булевого значення. Вони просто приводяться до рядку, хоча числові значення працюють нормально.
Приблизно така ж проблема з вкладеними параметрами.

Обидва мінуса з легкістю можна обійти, якщо використовувати raw форму запису, але все ж неприємно. А от плюси виглядають куди більш вражаюче.

Що ж ми маємо в сухому залишку

Написання запитів у Postman проходить простіше, швидше і виглядає читабельний. Що стосується виконання самих запитів — то тут, швидше за все, різниця не суттєва. Але ось що точно можна сказати, так це те, що на запуск тестів з використанням Newman не потрібно додатковий час, як у випадку з Cypress.

Приміром, на даний момент наша колекція включає в себе 60 запитів і більше 100 перевірок, але на їх виконання локально йде в середньому 15 секунд. На віддаленому сервері ж ця цифра ще менша і деколи досягає 9 секунд, що порівнянно з часом запуску одного Cypress.

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

Після проведеного дослідження я зупинив свій вибір на Postman, так як нам потрібно буде запускати ці тести досить часто, і час буде досить критичним. До того ж можливість згенерувати документацію зіграла не останню роль, так як, по суті, детального опису, та ще й з прикладами в єдиному місці у нас досі не існувало.

Висновки

У цій статті я хотів передати свій досвід у виборі інструменту, але не в якій мірі не наполягаю на тому, що він єдино правильний. Ваш вибір може залежати від ваших завдань, потреб і обмежень і може відрізнятися від поточного. Наступного разу я розповім більш докладно про самому тестуванні в Postman і, зокрема, про такий бібліотеці, як tiny-json-validator , яка вже входить в набір підключених бібліотек Postman і дозволяє перевіряти схему відповіді і типи даних в ньому. На цьому бажаю вам легких і правильних рішень :)

Опубліковано: 06/12/18 @ 08:34
Розділ Різне

SEO Блог