Тестирование процессов смены email в React без путаницы со ссылками
Смена email аккаунта кажется мелочью. На самом деле это серьезный источник ошибок при тестировании.
Тестировщики часто путают ссылки подтверждения. Один человек обновляет адрес, а другой первым открывает сообщение. Это создает путаницу. Команда начинает спорить, сломана ли страница в React или ссылка принадлежит не тому пользователю.
Эта проблема возникает потому, что команды относятся к почтовому ящику как к общему инструменту. Вы же должны относиться к почтовому ящику как к части контракта фичи.
Процессы смены email хрупки. Они изменяют активную учетную запись. Пользователь уже вошел в систему. Часто возникает состояние гонки между ожидающим (pending) и подтвержденным (confirmed) email.
Распространенные проблемы включают:
- Сообщения с подтверждением приходят в общий почтовый ящик, и их невозможно отследить.
- UI показывает старые данные даже после того, как ссылка подтвердила новый запрос.
- Бэкенд обновляется, но кэш фронтенда показывает старый адрес.
- Один тестировщик нажимает на ссылку, предназначенную для другого человека.
Общий почтовый ящик мешает найти причину бага. Используйте уникальный временный (burner) email-адрес для каждого запуска теста вместо одного алиаса для стейджинга.
Следуйте этой четкой последовательности:
- Создайте тестового пользователя.
- Запросите смену email на экране настроек в React.
- Отправьте письмо через реальный путь бэкенда.
- Направьте сообщение в ящик, принадлежащий только этому тесту.
- Откройте ссылку и убедитесь, что экран настроек обновился с новым адресом.
Это обеспечивает прозрачность владения. Вы будете точно знать, какая ссылка пришла от какого пользователя.
Для React-приложений соблюдайте одно дополнительное правило. Делайте утверждение (assert) только после свежего чтения данных. Не доверяйте оптимистичному состоянию клиента (optimistic client state). Мутация может вернуть успех, но перезагрузка страницы может вернуть старое значение, если бэкенд не завершил изменение.
Хороший сквозной (end-to-end) тест должен проверять следующие моменты:
- Письмо пришло на ожидаемый адрес, а не на старый.
- Ссылка ведет на правильный хост окружения.
- Ссылка обновляет запись аккаунта.
- Старый адрес исчезает после refetch.
- Повторное использование той же ссылки безопасно завершается ошибкой.
Если кэш React query или клиентское хранилище устарели, фича будет казаться сломанной. Клиенту важно только то, отображает ли экран настроек реальность.
Также стоит добавлять correlation ID к каждому запросу. Это поможет отследить путь запроса от пользователя до доставки сообщения и финального подтверждения.
Изолированные почтовые ящики не заменяют юнит-тесты. Используйте юнит-тесты для валидации форм и ошибок API. Используйте поток с почтой, чтобы доказать, что реальный путь пользователя работает во всех системах.
Перед тем как выпускать изменения в настройках аккаунта, проверьте следующее:
- Запросите изменение через реальный React UI.
- Убедитесь, что сообщение попадает в ящик, привязанный к конкретному запуску.
- Проверьте, что новый адрес отображается после refetch.
- Убедитесь, что старую ссылку нельзя использовать повторно.
- Подтвердите, что в логах аудита видно, кто инициировал изменение.
Это предотвращает баги, когда в изоляции всё выглядит нормально, но в реальном мире всё ломается.