Як тестувати за допомогою Postman?
Як я і обіцяв у попередній статті — ось вам невеличка історія про те, як організовувати тестування безпосередньо у Postman.
Я неодноразово помічав цікавий факт, що люди, котрі не повʼязані із тестуванням API, або із його створенням, доволі рідко помічають таку вкладку як “Tests”. Не. дивлячись на те, що вона таїть в собі широкий функціонал, так само як і “Pre-request script”.
Як зазвичай ми перевіряємо успішність виконаного запиту? Найбільш простий спосіб — за кодом відповіді. І її досить легко реалізувати в Postman, вам навіть не доведеться власноруч писати код. Все що необхідно — це вибрати `Status code: Code is 200` сніппет у вкладці “Test” і побачити наступний результат:
Якщо ж ви очікуєте інший код аніж 200, то просто змініть на наобхідний в назві тесту і в параметрі методу ‘status()’. Результат — ви щойно створити ваш перший Postman тест.
Вкладки “Pre-request” і“Tests”
Тепер розглянемо власне що із себе уявляють вкладки “Pre-request” и “Tests”. І для початку почнемо власне із вкладки “Test”.
Як і очікується, код із цієї вкладки почне своє виконання після отримання відповіді від сервера і наші тести зможуть працювати із результатами цього запиту. Але що саме ми можемо перевірити? Для початку варто піти найлегшим шляхом і переглянути, що пропонують нам сніппети праворуч. Там ми побачимо велику кількість доступних прикладів, котрі покриють більшість наших потреб:
- перевірка статус коду;
- перевірка наявності строки у відповіді чи конкретного значення в JSON;
- перевірити час до відповіді;
- або ж навіть конвертувати XML у JSON обʼєкт, для зручності взаємодії із ним
Все це вже готово і доступно вам за натисканням відповідного пункту в прикладах. Залишиться тільки виправити все під свої параметри, і тести будуть готові.
Я б хотів детальніше розглянути певний сніпет під назвою “Використання Tiny Validator для даних JSON”. У ньому використовується бібліотека, яка дозволяє порівнювати схему відповіді. Перевіряти структуру, наявність обов’язкових властивостей і навіть типи даних, що містяться в них. Користь від цієї бібліотеки можна оцінити лише порівняно зі складністю її застосування, оскільки сніпет дає нам лише приблизне розуміння того, як використовувати дану бібліотеку.
Давайте все ж таки розглянемо ті елементи, які надає нам сніпет. У перших п’яти рядках нам показують, як створюється схема, за якою потім буде проводитись порівняння відповіді. Саме цей аспект описаний дуже мінімально. У даному прикладі нам демонструють опис відповіді у вигляді масиву булевих значень. Це не найскладніший приклад, але я сумніваюся, що на всіх ваші проектах кожен маршрут надає подібну відповідь (інакше життя тестувальника було б набагато простіше, і він, можливо, навіть занудьгав би 😉).
Зазвичай типова відповідь представляє собою об’єкт з кількома властивостями. Ці властивості, в свою чергу, можуть бути простими типами (рядок, число) або трохи складнішими для перевірки, наприклад, масивом або вкладеним об’єктом. Як же все це перевірити? Уявімо, що наша відповідь виглядає наступним чином:
{
"args": {},
"data": {
"method": "POST"
},
"files": ["some file name", "other file name"],
"url": "https://postman-echo.com/post"
}За допомогою сніпету буде досить проблематично скласти схему відповіді для даного прикладу. Однак, знаючи всього кілька пунктів, це не так вже й складно зробити:
- для відкриття об’єкта слід використовувати ключ properties;
- для опису елементів у масиві слід використовувати items;
- доступні типи даних: string, number, boolean, array, object, null.
Давайте ж поглянемо, як буде виглядати схема для нашого прикладу:
{
type: 'object',
properties: {
args: {
type: 'object'
},
data: {
type: 'object',
properties: {
method: {
type: 'string'
}
},
files: {
type: 'array',
items: {
type: 'string'
}
},
url: {
type: 'string'
}
}
}Так, стає трохи зрозуміліше (сподіваюся). Ми впоралися зі складанням схеми, тепер подивимося далі на сніпет. В ньому зберігаються два масиви у змінні, це тестові дані. Було б доцільніше замінити цей код на наступний:
const jsonData = pm.response.json();Тут ми зберігаємо в константу jsonData вже розпарсену відповідь у форматі JSON. Здається, все зрозуміло.
Остання частина коду з сніпету — безпосередньо тест. Усі тести в Postman оформлюються в одному стилі. Ми викликаємо метод test у глобального об'єкта pm, куди передаємо назву тесту і callback-функцію з кодом для тесту. Всередині використовується підхід запису перевірки в стилі BDD з використанням chai, де ми викликаємо метод validate у бібліотеці tv4, куди передамо створену нами схему та відповідь у форматі JSON.
Але здається, що я трохи занадто захопився(хоча я ще не розповів усі особливості роботи з цією бібліотекою), а втім, у цій статті є ще багато чого цікавого для розповіді. Давайте поглянемо на вкладку “Pre-request Script”. Для чого взагалі її варто використовувати?
Як ви могли здогадатися, і як повідомляє Postman, цей скрипт буде виконаний безпосередньо перед відправленням запиту. Отже, варто використовувати цю вкладку для підготовки тестових даних, наприклад, згенерувати випадкове значення або виконати допоміжний запит. Наприклад, вам потрібно отримати останню опубліковану статтю, і в цьому запиті ви будете до неї звертатися. Є два способи її отримати. Перший — зробити запит окремо і передати значення через змінну середовища (про це ми поговоримо нижче), або виконати цей запит у pre-request script. Плюсом останнього буде те, що в разі відлагодження, якщо вам знадобиться виконати цей запит, всі інші необхідні дії виконаються автоматично, і вам не доведеться згадувати, де знаходиться необхідний запит, виконувати його, а потім вже приступати до відлагодження. Виконати запит можна за допомогою наступного методу:
pm.sendRequest(request, function (err, response)){}Більше прикладів можна переглянути на офіційному веб-сайті документації. Існують способи виконання pre-request scripts для всієї папки або навіть для всієї колекції. Але це вже питання вибору та трохи виходить за рамки цієї статті.
Змінні оточення і не тільки
Однією з ключових особливостей Postman, яка є надзвичайно корисною для написання тестів, є можливість передавати змінні з одного запиту до іншого за допомогою змінних середовища. Додавши їх до своєї колекції і витративши трохи часу на збереження необхідних значень в них та подальше використання, ви отримаєте багато задоволення від використання цього інструменту і навіть зможете здивувати розробників зручністю і продуманістю, якщо поділитесь з ними своєю колекцією 😉
Створити файл досить просто: у правому верхньому куті натисніть на іконку шестерні, а потім на кнопку “Додати”. Введіть ім’я файлу і знову натисніть “Додати”. Тепер у вас є файл, в який ви можете зберігати змінні і потім використовувати їх. Я думаю, не варто довго розповідати, для чого це може бути використано. Логін, передача ідентифікатора та іншої інформації — все це легко реалізувати за допомогою змінних середовища. Нижче наведені приклади запису та зчитування змінної середовища, але ви також можете знайти цей код у сніппетах.
pm.environment.set("variable_key", "variable_value");
pm.environment.get("variable_key");Але змінні середовища — це не єдиний тип змінних, які доступні вам в Postman. Існують також глобальні змінні, які будуть використовуватися у всіх колекціях, є локальні змінні, які існують лише в межах одного запиту, а також змінні колекції. Але їхнє застосування буде трохи обмежені, і варто їх використовувати тільки у випадках, коли змінні середовища явно не підходять для ваших потреб.
Запуск коллекції через графічний інтерфейс чи черезе терміна
У попередній своїй статті я вже згадував про пакет npm Newman, який дозволяє запускати ваші колекції з консолі, що легко інтегрується у ваш CI/CD, попередньо обгорнувши це все в Docker-контейнер, щоб прославити богів DevOps. Вам просто потрібно встановити пакет і потім викликати його, передаючи файл колекції та змінні середовища. Для цього вам потрібно експортувати відповідні файли з Postman.
Єдине суттєве обмеження полягає в тому, що неможливо перезаписати значення змінних середовища з консолі. Для вирішення цієї проблеми я використовую глобальні змінні. Хоча це не найкращий варіант, але єдиний доступний. Це реалізується за допомогою прапорця:
--global-var “<global-variable-name>=<global-variable-value>”Щодо запуску через сам Postman, ви також не обмежені виконанням окремих запитів. Ви можете виконати всю колекцію та вибрати відповідний файл змінних для неї. Крім того, ви можете вибрати кількість запусків, вказати файл з даними, час затримки та те, що саме ви хочете вести журналування.
І навіть це все ще не все. При платній підписці ви отримуєте можливість запускати ваші колекції на віддалених серверах з заданою періодичністю. Вам доступні шість регіонів на вибір. Це відмінний вибір для невеликих команд, які ще не налаштували CI/CD. Ви можете не тільки запускати тести, але й перевіряти швидкість відгуку для різних регіонів.
Висновок
Підсумовуючи хотілося б сказати наступне: Postman надає безліч можливостей для тестування вашого API. Це не тільки створення запиту та його виконання поодинці, але й набагато складніші та, що найголовніше, автоматизовані дії. В нашій команді наразі всі тести API створені з його використанням. Більше того, самі розробники використовують його для початкового тестування API і потім передають колекції з роутами для покриття тестами. Все це працює дуже злагоджено, і на сьогоднішній день ми не маємо сумнівів у правильності вибору інструмента для тестування.
Якщо у вас виникли питання щодо Postman, залишайте коментарі, і я з радістю допоможу вам, якщо зможу.
