不安定なテストを構築せずに一時的な電子メール API を使用する方法

電子メール テストは、間違った理由で合格する可能性があります。共有受信トレイには昨日のコードが含まれている可能性があり、固定の 10 秒スリープは静かな朝に機能する可能性があり、期限のない再試行ループにより、アプリケーションが失敗した後も CI ワーカーが長時間占有され続ける可能性があります。

信頼性の高い一時電子メール API テストは、作成、トリガー、ポーリング、照合、アサート、クリーンアップという小さなステート マシンです。各段階には、明確な所有者、期限、およびメッセージ自体が漏洩しない証拠が必要です。

フローを自動化する前に、より広範な 電子メール テスト チェックリスト ] を使用して、どの配信、レンダリング、セキュリティ動作がテスト スイートに属するかを決定します。

すべてのテスト実行に独自の受信箱を与える

1 つのテストまたは密接に関連する 1 つのシナリオ用に新しい受信トレイを作成します。並列ワーカーに同じアドレスを読み取らせないでください。アドレスだけでなく、返された受信箱識別子をテスト コンテキストに記録します。後続のリクエストはその不透明な識別子を参照する必要があります。

メールを送信するアクションの直前に受信箱を作成します。これにより、時間枠が狭くなり、古いメッセージが弱いアサーションを満たすことができなくなります。テスト ランナーが失敗したジョブを再試行できる場合は、記憶に残る電子メール アドレスを選択するのではなく、ローカル診断メタデータにその実行識別子を含めてください。

1 つの監視可能なアクションをトリガーする

テスト対象のシステムに、確認リンクの送信、サインイン コードの配信、または領収書の発行という 1 つのアクションを実行するように依頼します。アプリケーションのリクエストまたはイベント識別子が提供される場合は、それをキャプチャします。この識別子は、件名のみの一致よりも強力な証拠となります。

未承諾のサードパーティ システムをテストしないでください。自動受信トレイは、あなたが所有するアプリケーション、または評価する権限を与えられたアプリケーション用です。これらは、アカウント ファーミング、プラットフォームの制御の回避、または他人の通信の監視のためのメカニズムではありません。

期限とバックオフを伴うポーリング

メール配信は非同期であるため、リストがすぐに空になるのは正常です。慎重にポーリングし、思い切って停止してください。有効な開始予算は、60 秒の期限で、1、2、3、5、8、そして 10 秒の待機時間です。多くのワーカーが一緒に開始すると、少しランダムなジッターが追加されます。

deadline = now + 60 seconds
delay = 1 second
while now < deadline:
    messages = list_messages(inbox_id)
    candidate = find_expected(messages)
    if candidate exists: return candidate
    sleep(delay + jitter)
    delay = min(delay * 1.6, 10 seconds)
fail("expected email did not arrive before deadline")

429 Too Many Requests およびすべての Retry-After 値を尊重します。レート制限後により積極的に再試行すると、テストが回復する可能性が低くなります。一時的な 5xx およびネットワーク障害は、元の期限内にのみ再試行してください。 1 分間のテストを黙って 10 分間のテストに変えないでください。

件名だけでなくトランザクションも一致させます

件名は人々向けに書かれており、変更される可能性があります。証拠の組み合わせを優先します。

• アクションの開始後にメッセージが到着しました。
• 受信者は、この実行用に作成された受信トレイです。
• 送信者のドメインが期待されています。
• 相関識別子またはワンタイムリンクはテストトランザクションに属します。
• 候補が 1 つだけ存在するか、テストで最新の有効な候補が明示的に選択されます。

メッセージ HTML を信頼できない入力として扱います。通常の閲覧プロファイルでスクリプトを実行したり、リモート画像をロードしたり、リンクを開いたりしないでください。ターゲット URL を抽出して解析し、制御されたテスト クライアントがそれに従う前に、その登録された宛先をアサートします。

秘密をテスト出力に含めないでください

API キー、確認コード、マジック リンクは、有効期間が短い場合でも認証情報となります。 API キーを CI シークレット ストアに配置し、認証ヘッダーに含めて送信します。これらをクエリ文字列、スクリーンショット、フィクスチャ ファイル、またはリポジトリ設定に決して配置しないでください。

失敗した場合は、境界付きメタデータ (受信ボックス識別子のサフィックス、タイムスタンプ、メッセージ数、編集された送信者ドメイン、HTTP ステータス、リクエスト ID) をログに記録します。ヘッダー、本文、添付ファイル、または完全なアドレスをダンプしないでください。有用なテスト レポートでは、ステート マシンが別のメールボックス アーカイブにならずに「どこで」停止したかが説明されています。

Finally ブロックでクリーンアップする

アサーションが成功するか失敗するかに関係なく、削除を実行する必要があります。受信トレイのクリーンアップをテスト フレームワークの finally、ティアダウン、または各フックの後に配置します。クリーンアップにより、偶発的な保持が減少し、後のテストが分離され、クォータの使用状況が理解しやすくなります。

削除が一時的に失敗した場合は、製品アサーションとは別に報告してください。元の失敗を隠さないでください。サーバー側のスケジュールされた有効期限はバックストップとして依然として価値がありますが、意図的なクリーンアップに取って代わるべきではありません。

並列化する前にクォータを計画する

シナリオごとのコールの見積もり: 1 つの受信箱作成、複数のリスト要求、1 つの詳細要求、および 1 つの削除。 10 人のワーカーが毎秒ポーリングを行うと、配信速度を上げずに共有制限を使い果たす可能性があります。ワーカーの同時実行性を制限し、文書化されたレート予算をテスト プロセス全体で共有し、アカウント ダッシュボードに毎月の消費量を表示します。

Once Email が計画している開発者レベルでは、無料のブラウザーの許可が API 自動化から分離されます。認証、エラー、クォータ、および価格設定の契約は、ライブ キーの処理、測定、およびサブスクリプションの取り消しが実稼働テストに合格した後に公開されます。これにより、製品の主張とユーザーが実際に検証できる機能が一致します。

最良の電子メール テストは、永遠に再試行するテストではありません。それは、隔離された受信箱を作成し、丁寧に待ち、適切な取引が到着したことを証明し、安全な証拠を記録し、メールボックスを残さないものです。