受信トレイの混乱を招かずにパスワードレスログインをテストする
デモでは、パスワードレスログインは簡単に思えます。ユーザーがメールアドレスを入力し、マジックリンクが届き、セッションが開始される。という流れです。
しかし、ステージング環境では、このフローは煩雑になりがちです。リンクが共有の受信トレイや古いエイリアスに届いてしまい、ノイズが発生します。
パスワードレス認証は、一つの完全なシステムとして扱う必要があります。JavaScriptクライアント、Node.jsバックエンド、メール配信、そしてセッションをテストしなければなりません。受信トレイのテストをスキップしてしまうと、たとえAPIテストに合格していても、壊れたフローをリリースしてしまう可能性があります。
よくある失敗例：
- リトライ後にバックエンドが2つのリンクを送信してしまう。
- メールのリンク先が誤ったホストを指している。
- 古いリンクが想定よりも長く有効なままになっている。
- クッキーがセットされる前に、フロントエンドがユーザーをサインイン済みとしてマークしてしまう。
テストを実行するたびに、隔離された受信トレイを使用してください。これにより、テストデータがチームのメールボックスに混入するのを防げます。ステージング環境では、実行ごとに分離を保つために使い捨てのメールサービスを利用しましょう。
隔離することでデバッグが容易になります。テストが失敗した場合、一つの受信トレイと一つのユーザーのジャーニーを確認できるはずです。どのメッセージがどのビルドに属しているかを正確に把握できる必要があります。
優れたテストは、以下のステップを順番に確認します：
- アカウントの存在を明かさずに、ログインリクエストが成功すること。
- 新しいマジックリンクがちょうど1通届くこと。
- リンクのホストがステージングドメインと一致すること。
- リンクによって有効なセッションが開始されること。
- 同じリンクを再利用すると失敗すること。
- 手動でリフレッシュしなくても、アプリのナビゲーションが更新されること。
Node.js側では、ログに相関ID（correlation ID）を付与してください。リクエストからメール送信、そして最終的なセッションに至るまで、そのIDを使用します。これにより、メールの遅延や重複が発生した際にバグを見つけやすくなります。
すべてのテストをメールテストに置き換えないでください。トークンのロジックやセッションのルールには、高速なユニットテストを使用しましょう。メールのパスは、実際のユーザー体験が機能することを証明するために使用します。
リリース前のチェックリスト：
- 1回のログインリクエストで、有効なリンクが1つだけ作成されること。
- ステージング環境において、最新のメールを容易に特定できること。
- リンクが正しいホストで動作すること。
- リンクが再利用できないこと。
- ログアウトして再ログインすると、クリーンな新しいトークンが作成されること。