Тестування процесів зміни email у React без плутанини з посиланнями
Зміна email-адреси облікового запису здається дрібницею. Насправді ж це серйозне джерело помилок під час тестування.
Тестувальники часто плутають посилання для підтвердження. Одна людина оновлює адресу, тоді як інша першою відкриває повідомлення. Це створює плутанину. Команда починає сперечатися, чи зламана сторінка React, чи посилання належить не тому користувачу.
Ця проблема виникає тому, що команди ставляться до поштової скриньки як до спільного інструменту. Ви ж повинні ставитися до поштової скриньки як до частини контракту функціоналу.
Процеси зміни email є крихкими. Вони змінюють активний обліковий запис. Користувач уже авторизований. Часто виникає стан гонки між очікуваною (pending) та підтвердженою (confirmed) email-адресами.
Поширені проблеми включають:
- Повідомлення про підтвердження надходять у спільну поштову скриньку, і їх неможливо відстежити.
- UI відображає застарілі дані навіть після того, як посилання підтверджує новий запит.
- Backend оновлюється, але кеш frontend показує стару адресу.
- Один тестувальник натискає посилання, призначене для іншої особи.
Спільна поштова скринька ускладнює пошук причини багу. Використовуйте унікальну тимчасову (burner) email-адресу для кожного запуску тесту замість єдиного аліасу для стейджингу.
Дотримуйтесь цієї чіткої послідовності:
- Створіть тестового користувача.
- Запитуйте зміну email на екрані налаштувань React.
- Відправте лист через реальний шлях backend.
- Направте повідомлення у скриньку, яка належить лише цьому тесту.
- Відкрийте посилання та переконайтеся, що екран налаштувань оновився з новою адресою.
Це забезпечує чітке володіння. Ви знатимете, яке посилання належить якому користувачу.
Для React-додатків дотримуйтесь одного додаткового правила. Перевіряйте (assert) стан екрана лише після свіжого зчитування даних. Не покладайтеся на оптимістичний стан клієнта (optimistic client state). Мутація може повернути успіх, але перезавантаження сторінки може повернути старе значення, якщо backend не завершив зміну.
Хороший end-to-end тест має перевіряти такі пункти:
- Email було надіслано на очікувану адресу, а не на стару.
- Посилання веде на правильний хост середовища.
- Посилання оновлює запис облікового запису.
- Стара адреса зникає після refetch.
- Повторне використання того самого посилання безпечно завершується помилкою.
Якщо ваш кеш React query або клієнтське сховище (client store) застаріли, функціонал здаватиметься зламаним. Клієнту важливо лише те, чи відображає екран налаштувань реальність.
Вам також слід додавати correlation ID до кожного запиту. Це допоможе відстежити шлях запиту від користувача до доставки повідомлення та фінального підтвердження.
Ізольовані поштові скриньки не замінюють юніт-тести. Використовуйте юніт-тести для валідації форм та помилок API. Використовуйте поштовий флоу, щоб довести, що реальний шлях клієнта працює в усіх системах.
Перед тим як випускати зміни в налаштуваннях облікового запису, перевірте наступне:
- Запитуйте зміну через реальний React UI.
- Переконайтеся, що повідомлення потрапляє в скриньку, присвячену конкретному запуску.
- Перевірте, що нова адреса відображається після refetch.
- Переконайтеся, що старе посилання не можна використати повторно.
- Переконайтеся, що логи аудиту показують, хто ініціював зміну.
Це запобігає появі багів, коли все виглядає добре в ізоляції, але не працює в реальному світі.