Все статьи

API-тесты быстрее, стабильнее и находят баги, которые UI никогда не покажет. Вот как писать их прямо в Playwright без дополнительных инструментов.

Playwright уже установлен. Вот как использовать его встроенный HTTP-клиент для тестирования API, наполнения тестовых данных и отказа от Postman.

API-тестирование не должно быть запасным вариантом, когда ломается UI. Это должна быть первая линия защиты для каждой бэкенд-фичи.

UI говорит «Заказ оформлен». SQL говорит, действительно ли запись попала в базу данных.

Ваши тесты Playwright проходят, но пройдут ли они, когда 500 пользователей одновременно обращаются к API? Учитесь k6: от первого скрипта до нагрузочного теста с порогами, интегрированного в CI.

Большинство багов авторизации живут в пробелах. Эндпоинт, возвращающий 200 вместо 401. Маршрут администратора, принимающий токен обычного пользователя. Учитесь тестировать всё это.

Фронтенд и бэкенд проходят собственные тесты, но API-контракт между ними ломается на стейджинге каждый второй спринт. Контрактное тестирование с Pact закрывает этот пробел.

GraphQL всегда возвращает 200, даже при ошибках. Вот как тестировать GraphQL API с Playwright, правильно обрабатывать модель ошибок и создавать переиспользуемые фикстуры запросов.

Коллекции Postman не запускаются в CI без платного плана. Фикстура request в Playwright делает то же самое, живёт в вашем репозитории и работает везде. Вот план миграции.

Каждое современное приложение, которое вы тестируете, общается с бэкендом через API. Поймите HTTP-запросы, статус-коды, аутентификацию и как проверять API-вызовы — без разработки.

Вы смотрите на вкладку Network. Запрос вернул 422. Это ожидаемо? Это баг? Нужно ли заводить тикет? Каждый QA-инженер, работающий с API, должен знать статус-коды, которые реально важны.

Postman — это то, с чего большинство QA инженеров начинают тестирование API. Не нужно писать код, чтобы отправлять запросы, проверять ответы и убеждаться, что бэкенд работает корректно.