Приведи пример негативного,тестового сценария для POST

Пример негативного тестового сценария для POST запроса

Негативный тест — это тест, который проверяет, как система обрабатывает некорректные, неожиданные или граничные входные данные. Его цель — выявить уязвимости, ошибки в бизнес-логике и обеспечить устойчивость приложения.

Контекст теста: Создание нового пользователя (User Registration API)

Рассмотрим API POST /api/v1/users, который создает нового пользователя в системе. Ожидаемое поведение для позитивного теста: успешное создание пользователя при отправке корректного JSON тела. Негативные тесты проверят все возможные отклонения от этого ожидания.

Пример негативного сценария: Отправка тела запроса с некорректным типом данных для поля email

Этот сценарий проверяет, что API правильно валидирует тип данных каждого поля и возвращает соответствующую ошибку, если вместо строки (string) для email отправлено число (integer).

Тестовые данные (некорректные):

{
  "username": "john_doe",
  "email": 12345,  // Ошибка: email должен быть строкой, а здесь integer
  "password": "SecurePass123!"
}

Ожидаемое поведение (Pass Criteria):

1. API НЕ создает пользователя в базе данных.
2. Возвращается статус код 400 Bad Request (или 422 Unprocessable Entity).
3. В теле ответа содержится понятное сообщение об ошибке, указывающее на проблему с полем email.
4. В ответе может присутствовать детализация ошибки (например, в каком поле и какая проблема).

Пример ожидаемого ответа:

{
  "status": "error",
  "code": 400,
  "message": "Invalid input data.",
  "errors": [
    {
      "field": "email",
      "message": "Field 'email' must be a valid string (email address)."
    }
  ]
}

Пошаговое выполнение теста:

1. Шаг 1: Сформировать HTTP POST запрос к эндпоинту /api/v1/users.
2. Шаг 2: Установить заголовок Content-Type: application/json.
3. Шаг 3: Включить в тело запроса (body) приведенный выше некорректный JSON.
4. Шаг 4: Отправить запрос.
5. Шаг 5: Проверить фактический ответ от сервера.

Проверки (Assertions):

# Пример проверок в коде теста (например, с использованием pytest и requests)
import requests

def test_post_user_with_invalid_email_type():
    url = "https://api.example.com/api/v1/users"
    invalid_data = {
        "username": "john_doe",
        "email": 12345,  # Неправильный тип
        "password": "SecurePass123!"
    }
    
    response = requests.post(url, json=invalid_data)
    
    # Assert 1: Статус код должен быть 400
    assert response.status_code == 400, f"Expected 400, got {response.status_code}"
    
    # Assert 2: Ответ должен быть в JSON формате
    assert response.headers['Content-Type'] == 'application/json'
    
    # Assert 3: В ответе должно быть сообщение об ошибке
    response_json = response.json()
    assert "error" in response_json or "errors" in response_json
    
    # Assert 4: Ошибка должна указывать именно на поле 'email'
    # Проверка может зависеть от структуры ответа API
    errors = response_json.get("errors", [])
    email_error_found = any(error.get("field") == "email" for error in errors)
    assert email_error_found, "No specific error for field 'email' found in response"

Почему этот сценарий важен (Цель теста)?

• Валидация бизнес-логики: Убеждаемся, что серверная логика правильно проверяет входные данные, а не полагается на клиента.
• Защита от ошибок: Предотвращает возможные внутренние ошибки сервера (например, 500 Internal Server Error), которые могли возникнуть при попытке обработки числа как email.
• Улучшение безопасности: Неправильная валидация может иногда приводить к уязвимостям.
• Ясность для клиента: Корректный ответ с ошибкой помогает клиентскому приложению (или пользователю) понять, что нужно исправить.
• Тестирование граничных случаев: Это один из многих возможных негативных случаев для POST.

Другие примеры негативных сценариев для POST /api/v1/users:

• Отправка пустого тела запроса ({}).
• Отправка JSON с отсутствующими обязательными полями (например, без password).
• Отправка email в формате, не соответствующем RFC (например, "not-an-email").
• Отправка пароля длиной менее минимально допустимого значения.
• Отправка дублирующегося email (попытка создать пользователя с email, который уже существует в системе).
• Отправка запроса с некорректным заголовком Content-Type (например, text/plain).
• Отправка чрезмерно большого тела запроса (проверка на лимиты).
• Отправка запроса без необходимых заголовков авторизации (если эндпоинт защищен).

Каждый из этих сценариев направлен на проверку разных аспектов устойчивости и корректности API.