Тестирование сценариев смены email без путаницы в ссылках
Смена email аккаунта кажется мелочью. Это распространенная ловушка для QA-команд. Один тестировщик обновляет адрес. Другой человек первым открывает письмо. Теперь команда спорит, сломана ли React-страница или ссылка принадлежала не тому пользователю.
Такая путаница возникает, когда вы относитесь к почтовому ящику как к общему инструменту, а не как к части функционала.
Сценарии смены email хрупки. Они изменяют активные аккаунты. Вы имеете дело с аутентифицированными пользователями и промежуточными состояниями (pending states).
Общие проблемы включают:
- Сообщения приходят в общий почтовый ящик без закрепленного владельца.
- Ссылка работает, но UI показывает старые данные.
- Бэкенд обновляется, но кэш фронтенда остается устаревшим.
- Тестировщики кликают по ссылкам, предназначенным для других тестировщиков.
Чтобы это исправить, используйте временный (burner) email для каждого отдельного прогона тестов. Не используйте один и тот же алиас на стейджинге.
Следуйте этой последовательности:
- Создайте тестового пользователя через приложение.
- Запросите смену email в настройках React.
- Отправьте письмо через реальный бэкенд.
- Направьте сообщение в одноразовый почтовый ящик.
- Откройте ссылку и убедитесь, что на экране настроек отображается новый адрес.
Изоляция обеспечивает прозрачность владения. Вам не придется писать запутанные заметки в Slack, чтобы вспомнить, какой ящик вы использовали.
Правило для React-приложений: всегда проверяйте экран после свежего чтения данных. Не доверяйте оптимистичному состоянию клиента (optimistic client state). Мутация может вернуть успех, но перезагрузка страницы может вернуть старое значение. Это случается чаще, чем принято считать.
Ваш сквозной (end-to-end) тест должен проверять:
- Email уходит на новый адрес в ожидании подтверждения (pending address).
- Ссылка ведет на правильный хост.
- Ссылка обновляет запись аккаунта.
- Старый адрес исчезает после повторного запроса данных (refetch).
- Повторное использование ссылки безопасно завершается ошибкой.
Ассерты (проверки) на фронтенде — самая важная часть. Лог бэкенда, говорящий об успехе, бесполезен, если пользователь видит неверный адрес. Если ваш кэш или стор (store) устарел, функционал сломан.
Трассируемость тоже помогает. Используйте correlation ID в ваших логах и метаданных письма. Это связывает запрос с доставкой и подтверждением.
Компромиссы, которые стоит учитывать:
- Опрос почтового ящика (polling) медленнее, чем моки.
- Временные адреса должны содержать только непроизводственные данные.
- Для preview-окружений нужны правила очистки.
Не пропускайте этот этап. Потоки email-уведомлений ломаются в разрывах между системами. Именно там моки наиболее слабы.