リンクの取り違えを防ぎ、メールアドレス変更フローをテストする
アカウントのメールアドレス変更は、一見些細なことに思えます。しかし、これはQAチームが陥りやすい罠です。あるテスターがアドレスを更新したとき、別の人が先にメールを開いてしまう。すると、Reactのページが壊れているのか、それともリンクが別のユーザーのものだったのかについて、チーム内で議論が巻き起こります。
この混乱は、受信トレイを機能の一部としてではなく、共有ツールとして扱ってしまうことで発生します。
メール変更のプロセスは脆弱です。アクティブなアカウントを変更するため、認証済みユーザーや保留状態（pending states）を扱うことになります。
よくある問題には以下が含まれます：
- 明確な所有者がいない共有受信トレイにメッセージが届く。
- リンクは機能するが、UIに古いデータが表示される。
- バックエンドは更新されるが、フロントエンドのキャッシュが古いままになる。
- テスターが他のテスター用のリンクをクリックしてしまう。
これを解決するには、テスト実行ごとに使い捨ての（burner）メールアドレスを使用してください。単一のステージング用エイリアスを使い回してはいけません。
次の手順に従ってください：
- アプリを通じてテストユーザーを作成する。
- Reactの設定画面でメールアドレスの変更をリクエストする。
- 本物のバックエンド経由でメールを送信する。
- メッセージを1回限りの受信トレイにルーティングする。
- リンクを開き、設定画面に新しいアドレスが表示されていることを確認する。
隔離（Isolation）によって、誰がどのデータを使っているかが明確になります。どの受信トレイを使ったかを忘れないために、Slackで煩雑なメモを残す必要もなくなります。
Reactアプリにおけるルール：常に最新のデータを読み込んだ後に画面を確認してください。楽観的なクライアント状態（optimistic client state）を過信してはいけません。ミューテーション（mutation）が成功を返したとしても、ページをリロードすると古い値が戻ってくることがあります。これは、自覚されている以上に頻繁に起こる現象です。
E2Eテストでは、以下の項目を検証する必要があります：
- メールが新しい保留中のアドレスに届くこと。
- リンクが正しいホストを指していること。
- リンクによってアカウントレコードが更新されること。
- リフェッチ（再取得）後に古いアドレスが消えること。
- リンクの再利用が安全に失敗すること。
フロントエンドのアサーション（検証）が最も重要です。ユーザーが間違ったアドレスを見ているのであれば、バックエンドのログに「success」と記録されていても意味がありません。キャッシュやストアが古い状態であれば、その機能は壊れているのです。
トレーサビリティ（追跡可能性）も有効です。ログやメールのメタデータに相関ID（correlation ID）を使用してください。これにより、リクエスト、配信、確認のプロセスを紐付けることができます。
検討すべきトレードオフ：
- 受信トレイのポーリングは、モックよりも時間がかかる。
- 使い捨てのアドレスには、本番環境以外のデータのみを保持させる必要がある。
- プレビュー環境にはクリーンアップのルールが必要である。
これを省略しないでください。メールのフローは、システム間の隙間で壊れるものです。そここそが、モックが最も脆弱になる部分なのです。