Тестирование беспарольного входа без хаоса в почтовом ящике
Беспарольный вход выглядит просто на демо. Пользователь вводит email. Приходит магическая ссылка. Сессия начинается.
В стейджинге этот процесс становится запутанным. Ссылки попадают в общие почтовые ящики или на старые алиасы. Это создает лишний шум.
К беспарольной аутентификации нужно относиться как к единой системе. Вам необходимо протестировать JavaScript-клиент, Node.js-бэкенд, доставку писем и сессию. Если вы проигнорируете почтовый ящик, вы можете выпустить сломанный флоу, даже если ваши API-тесты пройдены успешно.
Распространенные ошибки включают:
- Бэкенд отправляет две ссылки после повторной попытки.
- Письмо ведет на неверный хост.
- Старая ссылка работает дольше, чем должна.
- Фронтенд помечает пользователя как вошедшего в систему до того, как установится cookie.
Используйте изолированный почтовый ящик для каждого запуска тестов. Это предотвратит попадание тестовых данных в рабочие почтовые ящики команды. Для стейджинга используйте сервисы временной почты, чтобы разделять запуски.
Изоляция упрощает отладку. Если тест проваливается, вы должны видеть один почтовый ящик и один путь пользователя. Вы должны точно знать, какое сообщение относится к какой сборке.
Хороший тест проверяет эти шаги по порядку:
- Запрос на вход проходит успешно, не раскрывая, существует ли аккаунт.
- Приходит ровно одна новая магическая ссылка.
- Хост ссылки совпадает с вашим доменом стейджинга.
- Ссылка запускает валидную сессию.
- Повторное использование той же ссылки приводит к ошибке.
- Приложение обновляет навигацию без ручного обновления страницы.
На стороне Node.js прикрепляйте correlation ID к вашим логам. Используйте его от момента запроса до отправки письма и создания финальной сессии. Это поможет найти баги, если письма приходят с задержкой или дублируются.
Не заменяйте все свои тесты тестами через email. Используйте быстрые юнит-тесты для логики токенов и правил сессий. Используйте путь через email, чтобы доказать, что реальный пользовательский опыт работает корректно.
Чек-лист перед релизом:
- Один запрос на вход создает только одну активную ссылку.
- Последнее письмо легко распарсить в стейджинге.
- Ссылка работает на правильном хосте.
- Ссылку нельзя использовать повторно.
- Выход из системы и повторный вход создают чистый новый токен.