Что хотят услышать интервьюеры:

Тестирование API проверяет, что сервис корректно принимает запросы, возвращает ожидаемые ответы и соблюдает контракт. Важно показать понимание уровней проверки: функциональность, валидация данных, коды ответов, ошибки, авторизация и стабильность интеграции. Также ожидают знание отличий API-тестов от UI-тестов: они быстрее, дешевле и чаще ловят ошибки на уровне логики.

Определение:

Тестирование API — это проверка программного интерфейса приложения без участия пользовательского интерфейса. Цель — убедиться, что методы/эндпоинты работают по спецификации: принимают корректные данные, корректно обрабатывают некорректные, возвращают нужный статус, структуру ответа и данные.

Обычно API тестируют на уровне интеграции и функциональности. Для REST это запросы к ресурсам по HTTP, для SOAP — к XML-сообщениям, для GraphQL — к query/mutation и структуре ответа.

Пример использования:

Например, есть эндпоинт создания пользователя POST /users. Проверяется, что при корректном JSON сервер возвращает 201 Created, в ответе есть id, name, email, а при передаче пустого email приходит ошибка валидации.

POST /users
Content-Type: application/json

{
  "name": "Ivan",
  "email": "ivan@example.com"
}

Ожидаемый ответ:

201 Created
Content-Type: application/json

{
  "id": 123,
  "name": "Ivan",
  "email": "ivan@example.com"
}

Если отправить:

POST /users
Content-Type: application/json

{
  "name": "Ivan",
  "email": ""
}

то ожидается ошибка, например 400 Bad Request, с сообщением о некорректных данных.

Пояснение кода:

Код не требуется, потому что здесь важнее логика проверки, чем конкретная реализация. Пример выше можно разложить так: сначала отправляется запрос с валидными данными, затем проверяется код ответа, структура JSON и значения полей. После этого отправляется запрос с невалидными данными и проверяется, что сервис возвращает предсказуемую ошибку, а не 500 или некорректный ответ.

Ключевые моменты:

Проверяются не только статусы HTTP, но и тело ответа, заголовки, схема данных и бизнес-правила.
Важны позитивные и негативные сценарии: корректные данные, ошибки валидации, отсутствие авторизации, неверные параметры.
API-тесты обычно быстрее UI-тестов и лучше подходят для проверки логики и интеграций.
Для REST, SOAP и GraphQL подход похожий, но отличаются формат запросов и структура ответа.
Хорошая практика — проверять контракт API: обязательные поля, типы, коды ошибок, стабильность формата.
Часто используют автоматизацию, чтобы запускать API-тесты в CI/CD и быстро ловить регрессии.

Расскажите о тестировании API.