信頼性の低いメールテストは簡潔です：アドレスを作成し、5秒待機し、最初のメッセージを読み取り、それが今回の実行に属していることを期待するだけです。
信頼できるバージョンも依然としてシンプルですが、配信を非同期として扱います。ユニークなアドレスを作成し、開始時刻を記録し、期限内でポーリングし、目的のメッセージと照合し、製品のアクションを検証し、何かが失敗した際には十分なコンテキストを報告します。
API キーを URL に含めない
GPTMail のキーは X-API-Key ヘッダーで送信してください。?api_key= クエリパラメータに入れないでください。URL はブラウザの履歴、アクセスログ、監視システム、リファラーデータに定期的に保存されます。
X-API-Key: YOUR_API_KEYキーは CI のシークレットマネージャーに保存し、ログではマスクしてください。公開のデイリーキーは探索に便利ですが、制御された自動テストスイートでは、クォータと使用状況を追跡できるキーを使用すべきです。
現在のエンドポイントとレスポンス例は GPTMail API ドキュメントページ にて管理されています。
実行ごとに1つのアドレス
独立して実行可能なテストごとに新しいアドレスを生成してください。テストスイート全体で共有される受信トレイから正しさを導くべきではありません。
アドレス、シナリオ ID、環境、テスト開始時刻を記録します。これらの値により、古いメッセージを除外し、メッセージのシークレットをログに残さずに衝突を診断できます。
固定スリープではなく、期限に対してポーリングする
メール配信時間は変動します。固定の5秒スリープは、配信が速いときは無駄で、遅いときは不安定です。
制限付きループを使用します：
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)期限はテスト契約の一部です。パスワードリセットフローは、一括ニュースレタープレビューとは異なる制限が必要になる場合があります。遅い依存関係が CI ジョブ全体を黙って伸ばさないよう、制限は明示的に保ちましょう。
正確にマッチさせる
「受信トレイの最初のメッセージ」は有用なセレクタではありません。複数のシグナルでマッチさせます：
- 受信者が今回の実行で作成されたアドレスと一致すること；
- 作成時刻がトリガー時刻より後であること；
- 送信者が期待されるサービスに属していること；
- 件名またはメッセージタイプがフローと一致すること；
- メッセージ ID が既に使用されていないこと。
送信者が複数のコードを発行できる場合、最新のマッチするメッセージを選択してください。その ID をテスト出力に保持し、リトライ時に誤って再利用されないようにします。
リストマッチ後にのみ読み取る
受信トレイの一覧取得は安価な探索ステップであるべきです。選択された候補に対してのみ全文メッセージを取得してください。これにより不要な作業が減り、関係のないプロモーションメールの解析を回避できます。
6 桁の文字列が存在するだけでなく、ビジネス上の結果を検証してください。コードを送信するか期待されるリンクを開き、アカウントが正しい状態に遷移したことをアサートします。
レートリミットをシグナルとして扱う
API がクォータまたはレートリミットのレスポンスを返した場合、現在の試行を中止し、リセット情報を表面化してください。過度なリトライは明確な容量シグナルをノイズに変え、無関係なテストを遅延させる可能性があります。
テストランナーでの同時実行数を制限してください。特にスイートが多数のアドレスを一度に作成する場合は、小規模なワーカープールの方が、数百の同時ポーリングループよりもデバッグが容易です。
失敗を隠さずにクリーンアップする
クリーンアップは証拠が取得された後に実行すべきです。成功時はメッセージを削除するか、短期間の保持に任せます。失敗時は調査のためにアドレスとメッセージ ID を保護された CI アーティファクトに十分な期間保持し、その後削除します。
検証コード、プライベートリンク、完全な HTML 本文を公開ビルドログに出力しないでください。
リトライを冪等にする
テストは新しいアドレスで新たな実行としてリトライしてください。同じアカウントと受信トレイに対して同じリクエストを繰り返すとクリーンな状態から始まると仮定しないでください。送信者は古いコードを無効化したり、繰り返しリクエストを制限したり、重複招待を拒否したりする可能性があります。
ネットワークリクエストがタイムアウトした場合、“応答が受信されなかった”と“操作が実行されなかった”を区別してください。破壊的なリトライを行う前に観測可能な状態を確認します。
失敗箇所を報告する
有用な自動化失敗は以下の段階のいずれかを特定します：
- アドレス生成に失敗した；
- メールキューイング前に製品アクションが失敗した；
- 期限までにマッチするメッセージが到着しなかった；
- メッセージは到着したが内容が一致しなかった；
- 検証アクションが失敗した；
- クリーンアップが失敗した。
この分類により、断続的な「メールテスト失敗」をチームが所有できる作業に変換できます。
より大規模なテストマトリクスについては、実践的なメールテスト計画 をお読みください。配信診断には、検証メールが届かない：壊れたステップを見つける をご活用ください。