Developer & QA ナレッジセンター
開発者・QA向け使い捨てメール
登録、OTP、マジックリンク、パスワード再設定を、個人の共有メールボックスをテスト基盤にせず分離して確認します。
メールテストの失敗は、古いアドレスの再利用、前のOTPの取り違え、別環境へ向くリンク、複数テストが同じ受信箱を読むことなど、地味な原因から起こります。このクラスタは実際に届くメールとテスト設計に焦点を当てます。CIでプログラム的なアサーションが必要なら、通常のブラウザ受信箱は専用テストAPIの代替ではありません。
各ガイドは同じ一般論を繰り返さず、1つの具体的な失敗モードに焦点を当てます。
ユーザーが実際に受け取るフローをテストする
まずシナリオを分離し、次に本文、コードやリンク、対象環境、次の実行に影響を残さない後処理を確認します。
一時受信箱でメールフローをテストし、テストノイズを増やさない方法
新しい受信先で実際のメールを観測し、送信、配信、本文、環境、最終状態を分けて検証することで原因を追えるテストにします。
詳しく見る登録メール確認をフォーム送信からVerified状態までテストする方法
新しいアドレス、現在の確認メール、確認操作、最終的なverified状態までを1つの状態遷移として検証します。
詳しく見るメールOTPで間違ったコードを受け入れないためのテスト方法
OTPのrequest、最新性、resend、期限切れ、replay、最終状態を明示的に検証し、受信箱の数字だけに依存しません。
詳しく見るMagic Linkログインでsession bugまで検出するテスト方法
recipient、environment、link、redirectだけでなく、最後に作られた認証sessionのidentityまで確認します。
詳しく見るPassword Resetメールをテンプレートではなくsecurity flowとしてテストする方法
request、token使用、password変更、replay、最終loginまで追い、メール到着だけでrecovery成功と判断しません。
詳しく見る並列CIのE2Eメールテストに独立した受信箱が必要な理由
testまたはworkerごとにrecipientを分け、並列runが互いのmessage、OTP、reset token、cleanupへ干渉しないようにします。
詳しく見るメールテストのPollingとRealtime：delivery保証ではなく待機戦略として選ぶ
Pollingとeventは受信後の観測方法を変えるだけで、sender、queue、SMTP deliveryの時間を短縮するものではありません。
詳しく見る共有テストメールボックスがメールQAをflakyにする理由
人、retry、environment、parallel runが1つのmailbox stateを共有するとmessage ownershipが曖昧になります。
詳しく見る