Source: https://once-email.com/ja/blog/temporary-email-api-testing-guide テストと開発 · 2026年8月8日更新日 2026年8月20日 # 不安定なテストを構築せずに一時的な電子メール API を使用する方法 一時電子メール API テストの実用的な設計: 各実行を分離し、バックオフでポーリングし、適切なメッセージを識別し、秘密を保護し、常にクリーンアップします。 [Once Email 編集部, Once Email author Once Email 編集部]() レビュー Once Email 日本語編集レビュー このガイドでできること リーダーは、プロバイダーに依存しないワークフロー、実行可能な疑似コード、制限付き再試行バジェット、ステータス コード ポリシー、トランザクション一致基準、安全なログ フィールド、および分解ガイダンスを取得します。 記事ガイド この記事を読む価値 **独自分析** 受信ボックスの作成から、制限付きポーリング、メッセージの選択、アサーション、クリーンアップまでの 1 つの自動サインアップ テストをトレースします。これには、メッセージ本文を保持せずに役立つ失敗の証拠も含まれます。 **トレンドの背景** 電子メールのリンクとコードは、自動サインアップと回復テストでは依然として一般的ですが、並列 CI ジョブにより、共有受信トレイ、固定スリープ、無制限のポーリング、およびメッセージ本文のログの信頼性がますます低くなります。 **実用的な価値** リーダーは、プロバイダーに依存しないワークフロー、実行可能な疑似コード、制限付き再試行バジェット、ステータス コード ポリシー、トランザクション一致基準、安全なログ フィールド、および分解ガイダンスを取得します。 電子メール テストは、間違った理由で合格する可能性があります。共有受信トレイには昨日のコードが含まれている可能性があり、固定の 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 自動化から分離されます。認証、エラー、クォータ、および価格設定の契約は、ライブ キーの処理、測定、およびサブスクリプションの取り消しが実稼働テストに合格した後に公開されます。これにより、製品の主張とユーザーが実際に検証できる機能が一致します。 ## [「メールがない」ではなく段階を診断する]() CI 前に記録するのは、段階、上限付き時間、HTTP 状態、存在するリクエスト ID、候補数、秘密を含まない実行 ID だけです。アドレス、コード、リンク、件名、本文、添付名、API キー、完全なクエリは記録しません。 再試行前に分類します。トリガー拒否は対象アプリ、期限切れは配信待ち、` 429 ` または ` 503 ` は元の予算内で ` Retry-After ` に従い、複数候補は相関の曖昧さ、制御済み宛先の誤りはアサーション失敗、クリーンアップ失敗は元の結果と分けます。提供者が API、認証、削除、期限、レート制限を文書化しているかも確認します。Once Email は現在公開本番 API を提供しておらず、例は利用可能なエンドポイントではなく提供者非依存の設計です。 最良の電子メール テストは、永遠に再試行するテストではありません。それは、隔離された受信箱を作成し、丁寧に待ち、適切な取引が到着したことを証明し、安全な証拠を記録し、メールボックスを残さないものです。 ## [テスト設計を隠さず SDK を使う]() Once Email は TypeScript、Python、Java、Go、.NET、PHP、Ruby のテスト済みプレリリース SDK 候補を提供します。[SDK ページ]() からテストサービスで既に使う言語を選び、ソースディレクトリを確認してください。受信箱のポーリングだけのために別ランタイムを追加しません。 候補は言語レジストリではなく、不変の GitHub Release から取得します。` SHA256SUMS ` と照合し、同梱 README を読み、版を固定します。実際に公開されるまで npm、PyPI、Maven Central、NuGet、Packagist、RubyGems の架空コマンドは掲載しません。 SDK は HTTP の重複を減らしますが、期限、正しいメールの選択、クリーンアップは決めません。認可テストごとに受信箱、ポーリング所有者、期限を一つにし、` 429 ` の ` Retry-After ` を守り、` 503 ` と空受信箱を分け、曖昧な一致を失敗させ、` finally ` で削除します。版変更時は[受信専用 API 契約]() も確認します。 ## 関連ガイド 開発者向け電子メールテストチェックリスト: リクエストから有効期限まで 配信の欠陥を隠したり、セキュリティ制御を弱めたりすることなく、サインアップ、検証、パスワード リセットの電子メール フローをテストするための実用的で承認されたチェックリストです。 [開発者向け電子メールテストチェックリスト: リクエストから有効期限まで]() 秘密を暴露せずに電子メールテストの証拠を保存する方法 検証コード、リセットトークン、電子メールアドレス、識別子、無関係な個人データを削除しながら、有用なスクリーンショット、ヘッダー、バグレポートを作成します。 [秘密を暴露せずに電子メールテストの証拠を保存する方法]() Postfix と Dovecot の違い：受信メールサーバーの役割と切り分け Postfix、Dovecot、LMTP、キュー、IMAP の境界を理解し、証拠から受信障害の層を判断します。 [Postfix と Dovecot の違い：受信メールサーバーの役割と切り分け]() [電子メール認証コード: コピー、確認、使用するためのより安全な方法 電子メール検証コードを有効期間の短いシークレットとして扱います。リクエストを確認し、宛先を検査し、コードのみをコピーして、タスクが完了したらクリアします。]() [確認メールが届かない？安全なトラブルシューティングのチェックリスト コードを繰り返し要求したり、アカウントのセキュリティを弱めたりすることなく、アドレスの間違い、送信者の遅延、再試行、フィルタリング、メールボックスの制限に対処できます。]()