Какие коды ответов HTTP сервера ты знаешь и как их использовать в тестировании?

Валидация HTTP-кодов состояния (Status Codes) — это одна из первых и основных проверок в API-тестировании. Они сразу указывают на результат операции.

Классы кодов и ключевые примеры:

• 1xx (Информационные): Встречаются редко. Например, 102 Processing — сервер обрабатывает длительный запрос.

• 2xx (Успех):

  • 200 OK — стандартный успешный ответ для GET, PUT, PATCH. В тестах: Проверяем, что тело ответа соответствует ожидаемой структуре и данным.
  • 201 Created — ресурс успешно создан после POST (иногда PUT). В тестах: Обязательно проверяем наличие заголовка Location с URI нового ресурса и валидируем тело ответа.
  • 204 No Content — успешно, но тело ответа пустое (часто после DELETE или PUT). В тестах: Убеждаемся, что response.content пуст.
  • 206 Partial Content — сервер возвращает часть данных (используется для докачки файлов). В тестах: Проверяем заголовки Content-Range.

• 3xx (Перенаправление):

  • 301 Moved Permanently / 308 Permanent Redirect — постоянный редирект. В тестах: Проверяем, что клиент (или наш тестовый фреймворк) автоматически следует за новым URL из заголовка Location.
  • 302 Found / 307 Temporary Redirect — временный редирект. Разница в сохранении метода запроса (307 сохраняет, 302 может изменить POST на GET).

• 4xx (Ошибка клиента):

  • 400 Bad Request — общая ошибка валидации запроса. В тестах: Проверяем, что при отправке невалидных данных (неверный JSON, отсутствующие поля) возвращается 400, а в теле есть детали ошибки.
  • 401 Unauthorized — требуется аутентификация. В тестах: Проверяем endpoints, защищенные токеном, без авторизационных заголовков.
  • 403 Forbidden — доступ запрещен (аутентификация прошла, но прав недостаточно).
  • 404 Not Found — ресурс не существует. В тестах: Проверяем запросы к несуществующим ID.
  • 409 Conflict — конфликт состояния (например, попытка создать дубликат уникального поля). В тестах: Критически важный код для проверки бизнес-логики.
  • 422 Unprocessable Entity (WebDAV) — семантическая ошибка в запросе (похоже на 400, но более специфично). Часто используется в REST API.
  • 429 Too Many Requests — превышен лимит запросов (rate limiting). В тестах: Проверяем корректность работы ограничений.

• 5xx (Ошибка сервера):

  • 500 Internal Server Error — общая ошибка сервера. В тестах: Неожиданная 500-я ошибка — это дефект. Мы можем преднамеренно вызывать ее, тестируя обработку некорректных данных.
  • 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout — ошибки прокси, недоступности сервиса или таймаута. В тестах: Моделируем в интеграционных тестах, проверяя механизмы retry и fallback.

Пример автоматизированной проверки в тесте:

import requests
import pytest

def test_create_user_success():
    url = "https://api.example.com/users"
    payload = {"username": "testuser", "email": "test@example.com"}

    response = requests.post(url, json=payload)

    # Основная проверка кода состояния
    assert response.status_code == 201, f"Expected 201, got {response.status_code}. Response: {response.text}"

    # Дополнительные проверки для 201
    assert "Location" in response.headers
    created_user = response.json()
    assert created_user["id"] is not None
    assert created_user["username"] == payload["username"]

def test_get_nonexistent_user():
    response = requests.get("https://api.example.com/users/999999")
    # Ожидаем четкий 404, а не 500 или 200 с пустым телом
    assert response.status_code == 404