自社のSMS認証フローをエンドツーエンドでテストする

実際に何をテストするのか

認証フローには複数の可動部があり、それぞれが独立して壊れ得ます。良いテストはハッピーパスと失敗パスの両方を扱います。失敗処理こそ、ユーザーの信頼が得られるか失われるかの場所だからです。

• 送信：有効な番号に対してコードが生成され送出される。
• 受信・確認：正しいコードが受理され、セッションが昇格する。
• 拒否：誤った、期限切れの、再利用されたコードが拒否される。
• 上限：レート制限と再送クールダウンが設計どおりに動く。
• フォールバック：チャネルのエスカレーションとエラー状態が正しく描画される。

プロバイダーのテスト認証情報とマジックコードを使う

主要な各プロバイダーは、実際のメッセージを送らずにフローを動かす方法を提供します。Twilioには成功と特定の失敗応答をシミュレートするテスト認証情報とマジック電話番号があり、Vonage、Sinch、MessageBirdはサンドボックスモードとテスト番号を提供します。ローカルとCIの実行でこれらを使い、テストスイートが実際のキャリアに決して触れないようにしましょう。

• Twilio：成功／無効／失敗の結果を強制するテスト認証情報 + マジック番号。
• その他：サンドボックスのAPIキーと指定のテスト番号。
• テストとライブの認証情報を、分離され明確に名付けられた環境設定に置きましょう。

自分が管理するテスト番号を取得

実際にメッセージを届けるエンドツーエンドテストのために、テスト受信者として自分が所有するプログラマブル番号を取得し、プロバイダーのメッセージングAPI経由で届いたコードを読み戻して確認ステップへ投入しましょう。番号とアプリを自分が所有しているため、これは自社システムのクリーンな閉ループテストです。

1. 1

   テスト番号を取得

   プロバイダーのアカウントでテスト環境専用のプログラマブル番号を作りましょう。

2. 2

   送信をトリガー

   自社のサインアップ／確認エンドポイントを呼び、アプリがテスト番号へ実際のコードを送るようにしましょう。

3. 3

   APIでコードを読む

   プロバイダーのAPI経由でインバウンドメッセージを取得し、コードをプログラムで抽出しましょう。

4. 4

   完了とアサーション

   コードを確認エンドポイントに送り、セッションが昇格したことをアサートし、その後番号を解放しましょう。

CIで自動化

上記をパイプラインに組み込み、ビルドのたびに認証がチェックされるようにしましょう。コミットのたびに走る高速な単体・統合テストにはモック／サンドボックス経路を使い、コストを抑えるため実際の閉ループテスト（所有番号を使用）は夜間やリリース前の段階に留保しましょう。

• 高速レーン：コミットのたびにプロバイダーをモックするかテスト認証情報を使う。
• 低速レーン：所有番号への実送信テストを夜間やリリース前に。
• 失敗パスもアサート：期限切れコード、誤ったコード、レート制限応答。
• 合否だけでなく配信遅延の回帰にアラートしましょう。

ロジックだけでなく到達性もテスト

ロジックテストはコードが正しいことを証明しますが、メッセージが現実世界で届くことは証明しません。主要なキャリアと国の番号へ定期的に実際のテストトラフィックを送り、実際の到達率と遅延を測定し、ルーティングやフィルタリングの回帰をユーザーより先に捕まえましょう。