Как проводить API тесты?

Что проверяют

Умеете ли вы строить API-тесты как поддерживаемый набор, а не как пачку запросов с проверкой 200. Следом обычно спрашивают, как вы работаете с авторизацией, тестовыми данными и внешними зависимостями и как тесты встраиваются в CI.

Как отвечать

Для Python типичный стек: pytest плюс httpx или requests. Каркас ответа:

• фикстуры: клиент, базовый URL из переменных окружения, токен авторизации, тестовые данные, которые создаются и удаляются вокруг теста. scope="session" для дорогих ресурсов, function для данных;
• параметризация: @pytest.mark.parametrize для позитивных и негативных наборов, чтобы один тест покрывал классы входных данных;
• что проверять: статус, схему тела, конкретные значения, заголовки, побочный эффект (объект действительно создался, повторный GET его вернул). Схему удобно валидировать моделями Pydantic или jsonschema;
• негативные сценарии: 400 и 422 на невалидный ввод, 401 без токена, 403 с чужим токеном, 404, повторный POST и идемпотентность PUT;
• свой сервис: для FastAPI тесты гоняют без сети через TestClient или httpx.AsyncClient с ASGITransport, зависимости подменяют через app.dependency_overrides;
• внешние API: мокаются через responses, respx или pytest-httpx, чтобы тест не зависел от чужой доступности;
• контракт: Schemathesis генерирует запросы по OpenAPI-спецификации и находит падения на краевых данных.

Прогон в CI на каждый merge request, отчёт в JUnit XML или Allure, при большом наборе параллельно через pytest-xdist.

Где спотыкаются

Проверяют только код ответа. Сервис может вернуть 200 с пустым списком или ошибкой внутри тела, и тест это пропустит.

Пишут тесты, зависящие друг от друга: второй использует объект, созданный первым. При параллельном запуске или смене порядка набор рассыпается.

Забывают про таймауты. У requests таймаута по умолчанию нет, и зависший сервис вешает весь прогон. У httpx он есть и равен пяти секундам, что тоже стоит знать при медленных эндпоинтах.