Напишите автотест для API создания пользователя на pytest. Что и как будете проверять?
Короткий ответ
- Проверяю статус-код, тело и побочный эффект
- Фикстура даёт клиент и чистит созданные данные
- Параметризация покрывает негативные кейсы одним тестом
- Схему ответа валидирую, а не только пару полей
- Уникальные тестовые данные — без конфликтов при параллели
- Тест независим: сам создаёт и сам удаляет
API-тест проверяет статус, контракт ответа и реальный эффект в системе, оставаясь независимым и повторяемым благодаря фикстурам.
Как сказать вслух
пример ответаДелаю фикстуру с API-клиентом и генерацией уникальных данных, чтобы тесты не конфликтовали при параллельном запуске. В позитивном тесте проверяю три вещи: статус 201, корректность тела ответа и побочный эффект — что пользователь реально создан, запрашиваю его отдельным GET. Негативные сценарии — дубликат email, невалидные поля — покрываю параметризацией. После теста фикстура удаляет созданные данные, чтобы тест можно было гонять сколько угодно раз.
Подробный ответ
Основной ответ
Качественный API-автотест проверяет три слоя: протокол (статус-код, заголовки), контракт (структура и типы тела ответа — лучше валидацией схемы через jsonschema или pydantic-модели) и эффект (сущность реально появилась — подтверждается последующим GET или запросом в БД). Инженерные практики: фикстуры pytest создают клиент с базовым URL и авторизацией и гарантируют очистку созданных данных через yield-финализатор; тестовые данные генерируются уникальными (uuid, Faker), чтобы тесты были повторяемыми и параллелились; негативные сценарии (занятый email, пустые и невалидные поля, отсутствие обязательных) оформляются параметризацией — один тест, много наборов; проверки ошибок включают и код, и тело с сообщением. API-клиент выносится в отдельный слой, чтобы тесты не дублировали URL и заголовки. Такой набор запускается в CI на каждый pull request, потому что работает быстро и без браузера.
Ключевые моменты
- Три слоя проверки. Статус, контракт тела, побочный эффект — ответ 201 сам по себе ничего не гарантирует.
- Фикстуры и очистка. yield-фикстура удаляет созданное после теста; тесты не зависят друг от друга и от порядка.
- Параметризация негатива. @pytest.mark.parametrize превращает десяток негативных кейсов в читаемую таблицу.
- Уникальные данные. Генерация email через uuid избавляет от конфликтов при параллельном и повторном запуске.
Практический контекст
Частое задание на лайвкодинге и в тестовых заданиях для автоматизаторов. Оценивают структуру теста (Arrange-Act-Assert), владение фикстурами и параметризацией, привычку проверять эффект и чистить данные. Красный флаг для интервьюера — тест, который проходит только при первом запуске, потому что данные захардкожены.
Пример кода
import uuid
import pytest
import requests
BASE = "https://api.test.example.com"
@pytest.fixture
def new_user_payload():
return {"email": f"qa-{uuid.uuid4().hex[:8]}@test.com",
"name": "QA User", "password": "Str0ng!Pass"}
def test_create_user(api_token, new_user_payload):
headers = {"Authorization": f"Bearer {api_token}"}
resp = requests.post(f"{BASE}/users", json=new_user_payload,
headers=headers, timeout=5)
assert resp.status_code == 201
body = resp.json()
assert body["email"] == new_user_payload["email"]
assert "password" not in body # пароль не возвращается
# побочный эффект: пользователь реально создан
got = requests.get(f"{BASE}/users/{body['id']}", headers=headers)
assert got.status_code == 200
# очистка
requests.delete(f"{BASE}/users/{body['id']}", headers=headers)Частые ошибки
- Проверяют только статус-код, без тела ответа и реального эффекта в системе
- Хардкодят email — тест падает со второго запуска из-за дубликата
- Не чистят созданные данные, и тесты начинают зависеть друг от друга