Декілька слів про автоматизацію тестування API
або чому я вибрав для цього саме Postman.
Ледь декілька тижнів тому я прийняв рішення написати API-тести для нашої дошки адміністратора новинного порталу. Для розв’язання цієї задачі існує безліч інструментів та способів, реалізованих на різних мовах.
Але спочатку кілька слів про себе. На даний момент я займаю посаду Automation QA в компанії Genesis Media. Ми розробляємо новинні сайти та редакційні системи для 4 країн Африки, а також Філіппін та Казахстану. І ось, у розриві між поточними завданнями, я вирішив, що не так погано автоматизувати наше API, враховуючи той факт, що до мене цього ніхто не робив і доведеться все починати з чистого аркуша. У мене були розвʼязані руки.
Які варіанти я розглядав
У мене з’явилося три найпростіших для мене рішення. Перший — автоматизувати все це у тестовому фреймворку для Selenium з використанням Java (я ж автоматизатор все-таки ;)). Другий — використовувати новомодний Cypress. Або все-таки використовувати спеціалізований інструмент, такий як Postman або SoupUI.
Перший варіант мені не подобався найбільше через складність впровадження. Наразі все налаштовано таким чином, що запуск вимагає цілої купи параметрів на CI або локально. Крім того, поєднувати UI-тести (end-to-end) з API-тестами (інтеграція) не є найкращою ідеєю з моєї точки зору. Ну і чесно кажучи, я давно не тестував API з використанням Java і просто не міг згадати всіх хитрощів або навіть бібліотек.
На користь Cypress говорило те, що я тільки що почав його використовувати і тримав руку на пульсі. Крім того, за допомогою нього вже було написано частину UI-тестів для цієї адмінки. А ті, хто використовував цей інструмент, знають, як дуже в ньому рекомендується використовувати API додатку для всього, що не є метою тестування у конкретному тесті. Тому в мене вже була частина готових API-запитів, і слід визнати, що Cypress зробив все, щоб робота з запитами не становила додаткових проблем.
Третій варіант був найпростішим і, можливо, найбажанішим. З Postman, напевно, працювали всі, хто якось пов’язаний з веб-розробкою, і він не потребує додаткових пояснень. Я був не винятком, але те, що мені ніколи не вдавалося зробити, це не просто перевірити конкретні ендпоінти, але й написати самі тести на їх основі.
Отже, для обґрунтованого вибору інструмента потрібно щось більше, ніж просто бажання (глибокий подих розчарування). Для порівняння я вирішив написати кілька простих запитів, включаючи вхід і створення статті, у Cypress та Postman з однаковими перевірками. Це мало дає можливість оцінити складність написання запитів, додавання до них тестів і врешті-решт зрозуміти, який з варіантів буде зручніше підтримувати в майбутньому. І, звісно, не варто забувати, що я зможу запустити ці самі тести і просто перевірити, який з них виконується швидше.
Cypress
Я почав з того, що вже було готово — з запитів у Cypress. Залишилося лише видалити зайве з коду і додати просту перевірку статусу. Отже, ось що у мене вийшло для запиту реєстрації та створення завдання:
На зображеному вище знімку екрана ми можемо побачити запит на логін і створення завдання з мінімальним набором обов’язкових полів (назви в JSON-схемі такі дивні через NDA та відсутність фантазії). Після кожного запиту ми порівнюємо отриманий код статусу з очікуваним. Все досить просто, навіть для мене — людини, яка недавно почала знайомство з JavaScript. Cypress дозволяє витягувати загальні змінні в файл cypress.json, що робить підтримку та параметризацію тестів досить зручною. Але що ж на рахунок швидкості виконання?
На цьому знімку екрана ви можете побачити Cypress runner і час, який знадобився для виконання двох тестів — 1.87 секунди, що не є поганим результатом. Але проблема полягає в тому, що вся інфраструктура вже піднята. Якщо ж запустити тести з консолі, як вони повинні запускатися в CI/CD, то лише на запуск самого Cypress йде більше десяти секунд. І це вже не так приємно. Хоча у нас буде трохи більше запитів, ніж зараз, піднімати такий великий клієнт для такої простої задачі вже не видається настільки доцільним.
Таким чином, ми маємо наступні переваги Cypress:
- Простий синтаксис при написанні тестів, який може зрозуміти навіть новачок за кілька днів;
- Готова інфраструктура з можливістю простого параметризованого запуску;
- Наявність інтерактивного ранера, де можна переглянути всі помилки прямо у консолі.
А що стосується недоліків:
- Дуже довгий час запуску;
- Потреба у написанні коду запитів (хоча він і не складний).
Не так багато мінусів.
Postman
Тепер давайте подивимось, як буде проходити процес з використанням Postman. Ось вам зразок запиту на скриншоті:
Тут все досить просто, особливо для тих, хто вже використовував Postman для тестування API. Просто записуємо всі параметри та їх значення у таблицю, додаємо до них описи за необхідності. Виділяємо URL в змінну середовища і використовуємо її для встановлення кінцевої точки. А у вкладці “Tests” вибираємо фрагмент коду для перевірки коду статусу відповіді. Єдине, з чим можуть виникнути проблеми у початківців, — це передача токену з відповіді на логін у наступні запити. Але це вирішується, знову ж таки, за допомогою запису змінної в середовище. А код для цього можна взяти у фрагменті з назвою “Set environment variable”.
Окей, запускаю тести як колекцію з самого Postman і отримую наступне зображення:
Результат — менше двох секунд на два запити. Приблизно такий самий результат (насправді він мав бути кращим, але Інтернет у новому офісі на момент написання статті не дав мені шансів). Але що ми побачимо, якщо запустимо це все з консолі?
Для вирішення цього завдання існує пакет npm Newman. Що ж, встановлюємо його, читаємо мінімальну документацію і запускаємо. Для цього експортуємо нашу колекцію з запитами та тестами, а також не забуваємо експортувати середовище, як звичайне, так і глобальне, якщо воно використовується. Команда для запуску проста:
newman run ім’я_файлу_колекції -e ім’я_файлу_середовища -g ім’я_файлу_глобального_середовища
В результаті бачимо ідентичні результати для окремих запусків, але різниця полягає в тому, що для старту знадобилося менше секунди.
Ну, давайте швидко поговоримо про переваги і недоліки (адже мені ще потрібно написати висновки, а ви, мабуть, вже втомилися все це читати).
Переваги:
- Інструмент, з яким знайомі багато людей і він дуже простий у використанні.
- Запити створюються швидко і для цього не потрібен жоден код, тому ними можуть користуватися всі без винятку.
- Дуже швидкий запуск тестів.
- Вбудована можливість спільного використання колекцій всередині робочої команди для платних акаунтів.
- Генерація документації для створених запитів і збережених відповідей.
Недоліки:
- При вказанні параметрів запиту у форматі form-data все ще можуть виникати неприємності, такі як неможливість передачі булевого значення. Вони просто конвертуються у рядок, хоча числові значення працюють нормально.
- Приблизно така сама проблема з вкладеними параметрами.
Обидва недоліки можна легко обійти, якщо використовувати формат запису “raw”, але все ж неприємно. Але переваги виглядають набагато вражаючіше.
І що ж ми маємо в кінці-кінців:
Написання запитів у Postman відбувається простіше, швидше і виглядає більш читабельно. Що стосується виконання запитів — ймовірно, різниця незначна.
Але однозначно можна сказати, що на запуск тестів з використанням Newman не потрібний додатковий час, як у випадку з Cypress.
Наприклад, на даний момент наша колекція включає 60 запитів і понад 100 перевірок, але їх виконання локально займає в середньому 15 секунд. На віддаленому сервері це число ще менше і часто досягає 9 секунд, що порівняно з часом запуску одного Cypress.
Також, просто не можу не відзначити захоплюючий функціонал з генерації документації. Це необхідно, якщо ваш API ще не має нічого подібного. Ви можете описати всю API в цілому, надати приклади запитів, відповідей і опис окремих параметрів. Для всього цього можна вибрати одну з кількох запропонованих мов. Усе це щастя можна розмістити як публічно, так і приватно.
Після проведеного дослідження я зупинив свій вибір на Postman, оскільки нам потрібно буде запускати ці тести досить часто, і час буде критично важливим. Крім того, можливість згенерувати документацію відіграла не останню роль, оскільки, по суті, докладного опису з прикладами в одному місці у нас до цього часу не існувало.
Завершуючи на цьому місці, я хочу висловити щиру захопленість вашою терплячістю і бажанням дізнатися більше. У своїй статті я хотів передати деякий досвід вибору інструменту, але зовсім не настоюю на тому, що він є єдиним правильним, а ваш вибір може залежати від ваших задач, потреб і обмежень, і може відрізнятися від поточного. Наступного разу я розповім більше про саме тестування в Postman і зокрема про таку бібліотеку, як tiny-json-validator, яка вже входить до набору підключених бібліотек Postman і дозволяє перевіряти схему відповіді та типи даних в ній. Бажаю вам легких і правильних рішень, а сам я йду на засіння.
