受信トレイの混乱を招かずにパスワードレスログインをテストする
デモでは、パスワードレスログインは簡単に思えます。ユーザーがメールアドレスを入力し、マジックリンクを受け取り、ログインするだけです。
しかし、ステージング環境では、このフローが崩れます。リンクが共有の受信トレイや古いメールエイリアスに届いてしまうからです。その結果、テストは混乱を極めます。
パスワードレス認証は、一つの統合されたシステムとして扱う必要があります。JavaScriptクライアント、Node.jsバックエンド、メール配信、そして最終的なセッションをすべてテストしなければなりません。
受信トレイの確認をスキップしてしまうと、APIテストはパスしても、ユーザーエクスペリエンスが失敗している可能性があります。
よくある失敗例：
- リトライ後にバックエンドが2つのリンクを送信してしまう。
- メールが誤った環境のホストを指している。
- 古いリンクが想定よりも長く有効なままになっている。
- クッキーがセットされる前に、フロントエンドがユーザーをログイン済みとしてマークしてしまう。
テストを実行するたびに、独立した受信トレイを使用してください。これにより、データがクリーンに保たれ、デバッグも迅速に行えます。3つのテストが1つの受信トレイを使用していると、エラーの特定が困難になります。
以下のワークフローに従ってください：
- UIまたはE2Eテストからログインをトリガーする。
- Node.jsにステージングパス経由でリンクを送信させる。
- 新しい独立した受信トレイでメッセージをキャプチャする。
- 同じブラウザセッションで最新のリンクを開く。
- 認証状態を確認する。
優れたテストとは、単にメールが届いたかどうかを確認するだけではありません。以下のステップを順番に確認してください：
- ログインリクエストが標準的な成功レスポンスを返す。
- 新しいマジックリンクがちょうど1つ存在する。
- リンクのホストがステージングドメインと一致している。
- トークンが有効なセッションを開始する。
- 同じリンクを再利用すると失敗する。
- アプリが手動の更新なしにUIを更新する。
バックエンドでは、ログに相関ID（correlation ID）を付与してください。これにより、リクエストの作成から最終的なセッションまでを追跡しやすくなります。
すべてのテストをメール駆動のテストに置き換えないでください。ロジックには高速なユニットテストを使用し、ステージングスイートにはこの受信トレイ経由のパスを使用してください。
リリース前にこのチェックリストを使用してください：
- ログインリクエストによって、有効なリンクが1つだけ作成される。
- ステージング環境において、最新のメールが解析しやすい。
- リンクによって正しいホストでユーザーがサインインされる。
- リンクを2回使用できない。
- ログアウトして再ログインすると、クリーンな新しいトークンが生成される。