Runner, data-driven і Newman

Collection Runner і data-driven тести

Collection Runner запускає всю колекцію або папку послідовно, з вибраним оточенням, кількістю ітерацій і затримкою між запитами. Результат — таблиця pass/fail по кожному pm.test.

Data-driven. У Runner підключаєш CSV або JSON-файл: один рядок = одна ітерація, колонки стають змінними. Зручно для граничних значень і негативних кейсів:

amount,currency,expectedStatus
150,UAH,201
0,UAH,400
-10,UAH,400
1000000000,UAH,422
150,XXX,400

У тілі запиту — {{amount}} і {{currency}}, у тесті:

pm.test(`amount=${pm.iterationData.get('amount')}`, () => {
  pm.response.to.have.status(Number(pm.iterationData.get('expectedStatus')));
});

Назва тесту містить значення з ітерації, тому у звіті видно, на якому саме рядку впало. Number(...) потрібен, бо значення з CSV приходять рядками. Так один запит покриває п'ять кейсів, а нові межі додаються рядком у файлі без зміни скриптів.

Newman і CI

Newman — CLI-запуск колекцій без інтерфейсу, для CI. Колекцію й оточення експортують у JSON і кладуть у репозиторій:

npm i -g newman newman-reporter-htmlextra
newman run bank-api.postman_collection.json \
  -e stage.postman_environment.json \
  -d transfers.csv \
  --env-var "password=$API_PASSWORD" \
  -r cli,htmlextra,junit

Якщо хоч один тест упав, Newman завершується з ненульовим кодом, і CI-джоба червоніє. JUnit-звіт підхоплюється Jenkins, GitLab і GitHub Actions. Секрети передають через --env-var з секретів CI, а не зберігають у файлі оточення.

Альтернатива від самого Postman — Postman CLI (postman collection run), який працює з колекціями з хмарного workspace.

HTML-звіт від htmlextra зручно зберігати як артефакт джоби: коли щось падає вночі, видно сирі запити й відповіді без повторного запуску.

Межа Postman

Великий набір API-тестів з логікою, фабриками даних і рев'ю в git легше підтримувати в коді: Playwright request, Cypress cy.request, RestAssured. Postman сильний для дослідження API, швидких перевірок і спільної документації з розробниками.

Причини, чому регресію переносять у код:

• Колекція в JSON погано читається в diff, і рев'ю змін у скриптах незручне.
• Важко перевикористовувати логіку: хелпери, фабрики тестових даних, спільні фікстури.
• У коді API-тести живуть поруч з UI-тестами, з тим самим CI, репортингом і типами.
• В API-тестах на TypeScript можна типізувати відповіді й ловити зміни контракту ще на етапі компіляції.

При цьому Postman я не відкидаю: коли приходить новий ендпоінт, я спершу досліджую його в Postman, а вже стабільні сценарії переношу в автотести. Імпорт OpenAPI в Postman теж економить час на старті.