Как устроена твоя коллекция в Postman
Вопрос
Расскажи, как ты организуешь коллекцию API-тестов в Postman, чтобы её можно было запускать в CI.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Папки по сущностям или сценариям, общие скрипты на уровне коллекции
Окружения dev/stage с baseUrl и учётками, секреты не в коллекции
Авторизация: получение токена в pre-request коллекции или отдельным запросом с сохранением в переменную
Цепочки через переменные, проверки статуса, схемы и ключевых полей в каждом запросе
Запуск через Newman или Postman CLI в CI с репортом, данные из CSV/JSON
Что могут спросить следом
- Как не хранить пароли в коллекции, которая лежит в git?
- Как сделать тесты независимыми друг от друга?
- Когда пора переходить с Postman на код?
Разбор
Я делю коллекцию на папки по сущностям: пользователи, заказы, оплаты, плюс отдельная папка сквозных сценариев. Общие вещи выношу на уровень коллекции: pre-request скрипт, который получает токен, если его нет или он истёк, и общие проверки вроде времени ответа и Content-Type. Адреса и учётки лежат в окружениях dev и stage, а секреты не коммитятся: их передаю в CI переменными или через --env-var. Запросы связываю переменными: создал заказ, сохранил id, дальше читаю, обновляю, удаляю. В каждом запросе проверяю статус, схему ответа и ключевые поля, а не только 200. Чтобы тесты не зависели от порядка и чужих данных, каждый сценарий сам создаёт себе данные и убирает за собой. В CI коллекция запускается через Newman или Postman CLI с JUnit-репортом. Когда логики становится много, условия, циклы, сложные данные, такие тесты лучше переносить в код, например pytest с requests или REST Assured.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.