2026 Cypress 16で登録メール認証コードをテストする方法？

準備段階：どのメール動作を確認するか

まず、対象が自社の開発環境またはテスト環境であることを確認します。実在する利用者や同僚の個人メールアドレス、本番アカウントは使わず、テスト専用アカウントと管理された受信先を用意します。テストデータに個人情報を含めない方針は、メールテストでのプライバシー対策にも関わります。

次に、テストで確認したい範囲を決めます。受信環境でメールを取得できても、それだけで一般のメールサービスへの配信や受信トレイへの到達を保証するわけではありません。

テスト環境のSMTPサービスや受信インターフェースを用意できる場合は、アプリケーションのメール生成と受信内容をそこで確認します。実際の外部配信も要件に含むなら、別途、管理された受信先を使うプレリリース確認を設けてください。テスト用アドレスの選び方を決める際は、受信先の比較ガイドも参照できます。

登録送信段階：実行ごとの識別情報を付ける

Cypressで登録フォームを送信する前に、今回のテストをメールと結び付ける方法を用意します。専用のテストアドレスを使う方法のほか、並列実行ごとに異なる受信先を割り当てる方法や、アプリケーションのテスト環境だけで使える実行識別子をメール情報に持たせる方法があります。

受信先と識別子は、メールを探す条件として使います。受信時刻だけを手掛かりにすると、前回の実行のメールや並列ジョブのメールを拾うおそれがあります。前回分を削除できる環境でも、対象アドレスや登録情報など、今回の実行に固有の条件を合わせて照合してください。

受信待機段階：Cypressのメール検証はどこで待つ？

ブラウザー上のCypressコマンドに、受信箱を直接読む役割を持たせるのではなく、メール確認をNode側のタスクまたはテスト環境のAPIに分けます。Cypressのcy.task()公式APIでは、ブラウザー外で処理を行うタスクを登録して呼び出せます。タスク側から受信環境を検索し、指定条件に一致するメールが見つかった時点で結果を返す構成にします。

// Cypressのテスト側。タスク名と受信処理はプロジェクトに合わせて実装します。
cy.task('waitForRegistrationMail', {
  recipient: testEmail,
  runId
}).then((message) => {
  expect(message).to.not.equal(null)
  const code = extractCode(message.text)
  cy.get('[name="verificationCode"]').type(code)
  cy.get('button[type="submit"]').click()
})

タスク登録はNode側のセットアップに置き、接続情報や認証情報をブラウザーへ渡さないようにします。公式APIの仕様に沿って、タスクが処理結果またはnullを返す形にしてください。結果がundefinedにならないことも確認します。具体的なメール検索方法は、利用するテスト用SMTPや受信インターフェースの仕様に従って実装してください。

待機は固定時間の休止ではなく、「条件に一致するメールが届いた」または「設定した期限までに届かなかった」で終了させます。これなら、到着の遅い環境では必要な範囲で待ち、届かない場合はタイムアウトとして診断できます。Cypress 16の変更履歴にバージョン情報があっても、それだけで個別のメール連携が動作するとは判断できません。判断に迷う場合は公式FAQも確認し、連携先の対応状況はその連携先の資料で照合してください。

認証段階：コードとアカウント状態を照合する

受け取ったメールからコードを抽出したら、まず対象の登録に対応するメールかを確認し、その後Cypressで入力して送信します。本文の書式変更で抽出処理が壊れないよう、テスト対象のメールテンプレートに合わせて抽出条件を明示し、抽出できなかった場合は件名や本文を安全に調べられる診断情報として残します。秘密情報や実在の個人データはログへ出さないでください。

認証後は、成功メッセージの表示だけで完了とせず、要件に応じて自社製品側のアカウント状態も確認します。画面の表示は利用者が見る結果の確認に使い、状態の確認にはテスト環境向けのAPIや管理可能なデータ層など、プロジェクトで管理している確認手段を使います。コードが拒否された場合は、入力値、対象アカウント、メールの識別条件、認証応答を記録し、どの段階で失敗したかを分けます。

再送・失敗分岐：前回のメールを読まない設計

Cypress登録メールのE2Eテストでは、成功経路だけでなく、同じ登録先への再送や、メールが見つからない場合の挙動も確認します。コードの有効期限、再送の間隔、以前のコードを無効にするかどうかは製品ごとの仕様です。普遍的なルールとして決めつけず、被テスト製品の実装と要件に合わせて期待値を置いてください。

判断条件

• 実行ごとに異なる受信先を用意できる場合は、そのアドレスを今回の登録に割り当てます。
• 受信先を共有する場合は、実行識別子や登録データを検索条件に加え、前回分を今回のメールとして扱わないようにします。
• 並列ジョブ同士を識別できない場合は、共有受信箱での並列実行を避けるか、テスト専用の受信インターフェースを分離します。
• 一致するメールが期限内に見つからない場合は、固定休止を延ばすのではなく、受信条件、アプリの送信処理、テスト環境の接続を順に調べます。

失敗分岐では、誤ったコードを送った場合の画面応答、該当メールが届かない場合の処理、認証が完了していないアカウントの状態をそれぞれ確認します。再送後に旧メールが検索結果へ残る構成なら、最新メールというだけで選ばず、実行識別子や登録情報との一致を優先してください。

CIとプレリリース段階：テスト範囲を分ける

CIでは、テスト環境内で登録処理がメールを生成し、指定の受信先で内容を取得できることを確認します。一方、実際の外部受信先への到達、迷惑メールへの分類、認証済み送信ドメインの設定状況まで確認したことにはなりません。外部配信が製品要件なら、管理された受信先を使うプレリリース検証を別に実行し、対象環境、受信先の条件、確認結果を記録します。

テスト用受信先は、登録要否や受信内容の保持条件、CI環境から接続できるかを確かめてから選びます。テスト専用の一時的な受信先を探している場合は、HourInboxを候補の一つとして確認できます。利用前にHourInboxの案内で現在の利用条件を確かめ、自社製品のテスト環境に適するか判断してください。銀行や決済など長期のアカウント復旧に使うアドレス、返信や継続受信が必要な用途には、管理下の長期利用メールアドレスを使うのが適切です。