Какой SQL-запрос используется для регистрации?

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

Для тестировщика вопрос не про синтаксис INSERT, а про то, умеете ли вы проверить регистрацию на уровне базы: что записалось, в каком виде и что будет с дублями. Следом обычно спрашивают, как вы убедитесь, что пароль не хранится открытым текстом.

Как отвечать

Приложение при регистрации выполняет INSERT в таблицу пользователей, часто вместе с записями в связанные таблицы (профиль, роль, токен подтверждения) в одной транзакции. Тестировщик сам обычно не вставляет, а проверяет результат через SELECT:

SELECT id, email, password_hash, status, created_at
FROM users
WHERE email = 'qa+reg01@example.com';

Что смотреть в выборке:

• пароль: лежит хэш (у bcrypt он начинается с $2a$ или $2b$, у Argon2 с $argon2id$), а не исходная строка и не MD5;
• уникальность: повторная регистрация с тем же email падает на ограничении UNIQUE, а API возвращает понятную ошибку, обычно 409 или 422;
• регистр и пробелы: User@Mail.ru и user@mail.ru не должны дать два аккаунта, это отдельный кейс;
• статус и даты: новая учётка в статусе «не подтверждена», created_at проставлен сервером, а не пришёл от клиента;
• атомарность: если упала вставка профиля, в users не должно остаться записи-сироты.

Добавьте, что тестовые данные вы помечаете (алиасы вида qa+...@) и чистите после прогона.

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

Предлагают INSERT IGNORE или ON DUPLICATE KEY UPDATE из MySQL как защиту от дублей. Первый молча проглатывает ошибку, второй перезапишет данные существующего пользователя, и для регистрации это дефект.

Проверяют только ответ API. Код 201 не гарантирует, что в базе всё записалось правильно, особенно если часть работы уходит в очередь.

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