Как протестировать POST-запрос для регистрации нового пользователя

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

Умеете ли вы строить проверки от контракта и рисков, а не останавливаться на «отправил, получил 201». Следом обычно спрашивают, как убедиться, что пользователь действительно создан, и что будет при двух одновременных запросах.

Как отвечать

Опирайтесь на контракт (OpenAPI или описание от разработчиков) и идите слоями:

• позитив: валидные данные, ожидаемый код (обычно 201 Created, но решает контракт), тело совпадает со схемой, пароля в ответе нет. Затем побочные эффекты: пользователь находится через GET или в базе, пароль лежит хешем, письмо подтверждения ушло (на стенде его ловит Mailpit или аналог);
• валидация: убрать каждое обязательное поле по очереди, пустые строки, null, неверный тип. Граничные значения: при минимуме пароля в 8 символов проверяются 7 и 8, так же для максимума. Ответ должен быть 400 или 422 с указанием поля, а не 500;
• email: невалидные форматы, пробелы по краям, регистр. Если User@Mail.ru и user@mail.ru считаются разными адресами, это почти всегда баг;
• дубликат: повторная регистрация с тем же email даёт 409 Conflict или то, что описано в контракте. Отдельно два параллельных запроса с одним email: без уникального индекса в базе появятся два пользователя;
• протокол: битый JSON, неверный Content-Type (415), не тот метод (405);
• безопасность: лишние поля вроде "role": "admin" или "is_verified": true должны игнорироваться (mass assignment), строки с HTML и SQL сохраняются как обычный текст, частые запросы упираются в лимит с 429.

Инструменты: Postman с прогоном через Newman в CI, код на pytest с requests или httpx, в Java REST Assured. Email в тестах генерируется уникальным на каждый прогон, созданные пользователи удаляются после теста.

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

Проверяют только статус-код. Сервер может вернуть 201 и ничего не сохранить или сохранить пароль открытым текстом.

Зашивают email константой. Второй прогон падает на дубликате, и тест становится нестабильным без всякого бага в продукте.

Забывают про mass assignment и гонку одновременных запросов, хотя именно там живут самые дорогие дефекты регистрации.