У цій статті підібрано 10 підказок та прийомів для спрощення та автоматизації завдання тестування API.

Порада №1: Написання тестів

    Логічно — першим кроком до тестування API є його розпочати, фактично розпочати автоматизоване тестування.     

    Для чого потрібно тестувати API?

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

    Оскільки Ваш код розростається і з часом змінюється — такого роду тести допомагають заощадити час, вчасно виявити поломки, що виникли.

      Написання автоматизованих скриптів тестування API у Postman — це надзвичайно просто. Ось приклад з використанням скриптів JavaScript. Тестування таких простих речей, як статуси HTTP, час відгуку та заголовки, можуть бути виконані одним рядком коду, дивіться:

Порада №2: Не змішуйте API тести та документацію в одне ціле

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

    З іншого боку, Ваші API тести переслідують цілком іншу мету. Перш за все, аудиторія відрізняється. Тоді як API — документація для споживачів API, самі тести для авторів API.

    По-друге, вміст відрізняється. Суцільний набір тестів буде включати в себе багато переваг для авторів API тестів, навмисні погані input -и (для тестування обробки помилок) і, навпаки можливо, міститиме велику кількість нерелевантної інформації, що буде зовсім незрозумілою для споживачів Вашого API.

     Кінці-кінців автори можуть різнитися. Документація (особливо публічні документи) частіше пишуться або редагується маркетинговою групою, Text writer -ами, тоді як автоматизовані тести API пишуть розробники, які створили API тести або тестувальники, які відповідають за перевірку API.

    З цих причин рекомендовано тримати API тести окремим файлом Postman Collections у документації API. Так, це означає, що Вам потрібно керувати двома різними тестовими документаціями, але вміст цих колекцій настільки сильно відрізняється, що між ними практично немає дублювання.

    І, як Ви побачите далі в цій статті, тести, розділені у власній колекції, відкривають деякі потужні можливості автоматизації. Поля опису, які Ви зазвичай використовуєте для документації API, можуть бути використані у якості описів тестових випадків. Це чудовий спосіб документувати свої тести, тому розробники та тестери знають, що тестується, що очікується, і т.д.

    А для того щоб тести, були зрозумілими та легко знаходились. Пропонуємо використовувати папки для групування запитів за ресурсами, test suite та робочими процесами.

Postman Collections folders

    А для того щоб тести, були зрозумілими та легко знаходитись. Пропонуємо використовувати папки для групування запитів за ресурсами, test suite та робочими процесами. 

Resources

Створіть папку верхнього рівня для кожного з Ваших API (користувачів, замовлень, продуктів тощо).

Test suite

Папки другого рівня містять тестові комплекти для кожного з Test suits. Добре організувати так: “Почати новий тест”, “Редагувати існуючий “, “Скасовані тести” тощо.

    Для простих тестів, для яких потрібен лише один тест API, третій рівень папок не потрібен. Ви можете просто створювати запити безпосередньо в папці Test suit. Обов’язково дайте своїм запитам змістовні імена, щоб відрізнити їх і чітко описати те, що вони тестують. Наприклад, папка тестового набору “Змінити існуючий порядок” може містити такі запити, як “Додати продукт”, “Видалити продукт”, “Змінити адресу доставки” тощо.

Workflows

    Папки третього рівня призначені для більш складних тестів, що охоплюють декілька викликів API. Наприклад, Ваш API при оплаті товару в корзині, може передбачати окремі запити, створення замовлення з кошика для покупок, ввести адресу доставки, вибір способу доставки та формування документу з платіжною інформацією. У такому випадку слід створити папку “Workflows” з назвою “Checkout”, яка міститиме всі ці запити.

Порада № 4: Перевірка схеми JSON

    Багато сучасних API використовують формат JSON Schema для визначення структури своїх запитів та відповідей. Postman включає в себе бібліотеку tv4, що полегшує написання API тестів для верифікації API згідно Вашої JSON Schema.

     Звичайно, Вам інколи захочеться «похардкодити» зі JSON Schema у Вашому тестовому скрипті, особливо якщо скрипт потрібен для багаторазової перевірки запитів. Таким чином, збережіть схему, як рядок JSON в змінному середовищі Postman. Тоді Ви зможете просто використовувати змінну в тестовому сценарії, як тут показано:

Порада № 5: Код повторного використання

     У попередній пораді показано, як легко повторно використовувати ту саму схему JSON для декількох запитів у Вашій колекції, зберігаючи її в змінному середовищі. Ви також можете повторно використовувати код JavaScript, використовуючи eval () функцію. Більшість API мають спільні правила, котрі застосовуються до багатьох (або всіх) кінцевих точок. Необхідно завжди встановлювати чіткі заголовки HTTP, або body відповіді повинен завжди знаходитись у певному форматі, або час відгуку завжди повинен перебувати в межах прийнятної межі. Замість того, щоб переписувати ці тести кожного запиту, можна написати їх один раз під час першого запиту Вашої колекції та повторно використовувати у кожному запиті після цього.

Перший запит у колекції Postman:

Всі наступні запити:

     Немає обмежень до обсягу збереженого коду у змінних і який може повторно використовуватися. Фактично, Ви можете використовувати цей трюк для повторного використання всіх бібліотек JavaScript, включаючи багато сторонніх бібліотек від NPM, Bower, GitHub.

Порада № 6: Поштовий майстер BDD

    За замовчуванням тестовий синтаксис Postman дійсно простий і легкий у вивченні, але й багато людей віддають перевагу синтаксису популярних тестових бібліотек JavaScript, таких як Mocha й Chai. Postman BDD дозволяє писати тести в Postman, використовуючи синтаксис BDD Mocha. Він використовує трюк “багаторазового коду” з попередньої поради для завантаження Chai та Chai-HTTP, означає:

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

Порада № 7: Автоматизуйте свої тести з Postman’s Collection Runner

    До сих пір ми зосереджувалися на одиничних запитах і тестуванні відповідей на них. Цей підхід чудово працює коли ми написали один тест, і бажаємо його постійно перезапускати. Але коли потрібно швидко виконати всі свої запити та побачити результати в одному представленні. Ось де Postman’s Collection Runner — прийде нам на допомогу.

interface Postman’s Collection Runner

Порада №8: Автоматизуйте свої тести з Newman

    Postman’s Collection Runner — це чудовий спосіб запустити всі Ваші тести та побачити результати одним махом, але він все ще вимагає від вас ініціювання запуску вручну. Якщо Ви захочете запустити тести Postman, як частину Continuous Integration or Continuous Delivery pipeline, то Вам потрібно буде використовувати Newman CLI.

    Newman легко інтегрується в Jenkins, AppVeyor, Bamboo, CodeShip, Travis CI, Circle CI або будь-який інший інструмент безперервного розгортання коду. Він підтримує різноманітні формати, включаючи User-friendly консоль, а також вихідні формати для файлів JSON або HTML.

Порада №9: Автоматизуйте свої тести за допомогою Postman Monitors

    Ви можете використовувати Postman Monitors для автоматичного запуску своїх тестів в Postman через регулярні інтервали, наприклад, кожну ніч або кожні 5 хвилин. Ви автоматично отримуватимете сповіщення про те, що який-небудь з Ваших тестів не пройшов, ба навіть можете інтегруватися з різними сторонніми послугами, такими як PagerDuty, Slack, Datadog та інші.

    Postman Monitors показує результати тесту в тому ж форматі, що й Postman’s Collection Runner, тому результати легко порівняти.

Postman monitors interface

Порада №10: Динамічне управління робочими тестами

    За замовчуванням Postman’s Collection Runner, Newman та Postman Monitors виконуватимуть кожний запит у Вашій колекції. Але Ви можете використовувати функцію postman.setNextRequest (), щоб змінити цей порядок. Це дозволяє умовно пропускати певні запити, повторити запити та ін.

    Функція setNextRequest () є оманливо простою, однак вона дає змогу використовувати всі можливі випадки використання, від створення списків відтворення Spotify до перевірки веб-сайту на пошкоджені посилання.

Джерело: http://blog.getpostman.com/2017/07/28/api-testing-tips-from-a-postman-professional/

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.