Скрипти і перевірки в Postman

Postman: змінні, скрипти, chaining

Області змінних від ширшої до вужчої: global, collection, environment, data і local. Вужча перекриває ширшу, тому однойменна змінна з environment перекриє глобальну. Environments дають змогу запускати ту саму колекцію на dev, stage і prod, просто перемкнувши середовище.

Pre-request script виконується перед запитом: генерація унікальних даних, отримання токена, обчислення підпису чи timestamp. Post-response script (раніше вкладка Tests) виконується після відповіді: перевірки через pm.test і pm.expect, наприклад статус, поля й час відповіді. Скрипти можна задавати на рівні запиту, папки і колекції.

Chaining — передача даних між запитами: після створення користувача зберігаю його ID через pm.environment.set('userId', json.id). Наступні запити використовують {{userId}}. Колекцію проганяють через Collection Runner з CSV чи JSON для data-driven тестів або через Newman у CI.

Pre-request, post-response і базові перевірки

Pre-request виконується до відправки запиту (підготувати дані, токен), post-response — після (перевірити відповідь, зберегти значення). Порядок: скрипт колекції, потім папки, потім запиту. Мова — JavaScript, асерти — Chai через pm.expect.

Базовий набір перевірок:

pm.test('Status 201', () => pm.response.to.have.status(201));
pm.test('Response time < 800 ms', () => {
  pm.expect(pm.response.responseTime).to.be.below(800);
});
pm.test('JSON content type', () => {
  pm.response.to.have.header('Content-Type');
  pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json');
});
const body = pm.response.json();
pm.test('Body fields', () => {
  pm.expect(body).to.have.property('id');
  pm.expect(body.status).to.eql('pending');
  pm.expect(body.amount).to.be.a('number').and.eql(150);
  pm.expect(body).to.not.have.property('cardNumber'); // чутливі дані не віддаються
});

Кожен pm.test — окремий рядок у звіті, тому краще мати кілька невеликих тестів з чіткими назвами, ніж один великий. Тоді з звіту Runner одразу видно, що саме зламалось.

Валідація схеми і ланцюжок запитів

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

const schema = {
  type: 'object',
  required: ['id', 'status', 'amount', 'currency'],
  properties: {
    id: { type: 'string' },
    status: { enum: ['pending', 'completed', 'failed'] },
    amount: { type: 'number', exclusiveMinimum: 0 },
    currency: { type: 'string', pattern: '^[A-Z]{3}$' }
  },
  additionalProperties: false
};
pm.test('Schema is valid', () => pm.response.to.have.jsonSchema(schema));

additionalProperties: false ловить ситуацію, коли бекенд раптом почав віддавати нове поле, наприклад внутрішній ідентифікатор. Це і захист від витоку даних, і сигнал про незадокументовану зміну контракту.

Ланцюжок запитів — передати дані з одного запиту в наступний:

// post-response у POST /accounts
pm.environment.set('accountId', pm.response.json().id);
// наступний запит: GET {{baseUrl}}/accounts/{{accountId}}

Корисні команди і сильний тест

Корисні команди:

• pm.sendRequest(...) — відправити допоміжний запит зі скрипту, наприклад отримати токен у pre-request.
• pm.execution.setNextRequest('Name') — змінити порядок у Runner; null зупиняє прогін. У старих колекціях трапляється postman.setNextRequest.
• pm.environment.unset('token') — прибрати за собою змінну.
• console.log(...) — вивід у Postman Console (знизу вікна): там видно сирий запит і відповідь, це головний інструмент дебагу.

Postman Console особливо корисна, коли змінна не підставилась: у ній видно фінальний URL і заголовки, і одразу ясно, чи пішов запит з {{token}} буквально, чи з реальним значенням.

Слабкий тест vs сильний. Перевірка лише статусу 200 пропустить порожній або хибний масив. Мінімум — статус, схема і ключові значення. Для запису — ще й наступний GET, щоб переконатися, що дані справді збереглися. Наприклад, після PATCH /accounts/42 з новою назвою я роблю GET /accounts/42 і перевіряю, що змінилось лише поле назви, а решта залишилась як була.