Reactにおけるメールアドレス変更フローのテスト：リンクの混同を防ぐ方法
アカウントのメールアドレス変更は些細なことに思えるかもしれません。しかし、実際にはテストエラーの大きな原因となります。
テスターは確認リンクを混同しがちです。ある人がアドレスを更新している間に、別の人が先にメッセージを開いてしまうことがあります。これにより混乱が生じます。チーム内で「Reactのページが壊れているのか、それともリンクが別のユーザーのものなのか」という議論が始まってしまいます。
この問題が発生するのは、チームが受信トレイを「共有ツール」として扱っているからです。受信トレイは、機能のコントラクト（契約）の一部として扱う必要があります。
メール変更のプロセスは脆弱です。それはアクティブなアカウントを変更するものであり、ユーザーはすでにログインしています。保留中のメール状態と確認済みのメール状態の間で、しばしばレースコンディション（競合状態）が発生します。
よくある問題には以下が含まれます：
- 確認メッセージが共有の受信トレイに届き、追跡する方法がない。
- リンクによって新しいリクエストが確認された後でも、UIに古いデータが表示される。
- バックエンドは更新されているが、フロントエンドのキャッシュに古いアドレスが表示される。
- あるテスターが、他の人のためのリンクをクリックしてしまう。
共有メールボックスを使用すると、バグの原因特定が困難になります。単一のステージング用エイリアスではなく、テスト実行ごとに一意の使い捨て（burner）メールアドレスを使用してください。
次のクリーンな手順に従ってください：
- テストユーザーを作成する。
- Reactの設定画面でメールアドレスの変更をリクエストする。
- 実際のバックエンドパスを通じてメールを送信する。
- メッセージを、そのテスト専用の受信トレイにルーティングする。
- リンクを開き、設定画面が新しいアドレスで更新されることを確認する。
これにより、所有権が明確になります。どのリンクがどのユーザーから来たのかが判明します。
Reactアプリの場合は、もう一つルールを追加してください。データの再取得（fresh data read）が行われた後にのみ、画面のアサーション（検証）を行ってください。楽観的なクライアント状態（optimistic client state）を信用してはいけません。ミューテーションが成功を返したとしても、バックエンドが変更を確定させていなければ、ページをリロードした際に古い値が戻ってくる可能性があります。
優れたエンドツーエンド（E2E）テストは、以下のポイントを検証する必要があります：
- メールが古いアドレスではなく、保留中のアドレスに届いたこと。
- リンクが正しい環境のホストを指していること。
- リンクによってアカウントレコードが更新されること。
- 再取得（refetch）後に古いアドレスが消えること。
- 同じリンクを再利用した場合に、安全に失敗すること。
React Queryのキャッシュやクライアントストアが古い（stale）場合、機能が壊れているように感じられます。顧客が関心があるのは、設定画面が現実の状態を表示しているかどうかだけです。
また、各リクエストに相関ID（correlation ID）を追加すべきです。これにより、ユーザーからメッセージの配信、そして最終的な確認に至るまで、リクエストを追跡しやすくなります。
受信トレイを分離することは、ユニットテストの代わりにはなりません。フォームのバリデーションやAPIエラーにはユニットテストを使用してください。受信トレイのフローは、すべてのシステムにわたって実際の顧客パスが機能することを証明するために使用してください。
アカウント設定の変更をリリースする前に、以下の項目を確認してください：
- 実際のReact UIから変更をリクエストする。
- メッセージが実行ごとの専用受信トレイに届くことを確認する。
- 再取得後に新しいアドレスが表示されることを確認する。
- 古いリンクが再利用できないことを確認する。
- 監査ログに誰が変更を開始したかが表示されていることを確認する。
これにより、単体では問題なさそうに見えても、実環境では失敗するといったバグを防ぐことができます。