browser isolationは外部mailboxまでは届かない
並列CIのE2Eメールテストに独立した受信箱が必要な理由
testまたはworkerごとにrecipientを分け、並列runが互いのmessage、OTP、reset token、cleanupへ干渉しないようにします。
PlaywrightのBrowserContextが完全に独立していても、同じメールアドレスへOTPを送ればテスト同士は競合します。並列CIではrecipientが共有backend dataになり、serial実行では見えないrace conditionが表面化します。
recipientもtest data
Playwrightはparallel worker間でunique backend dataを推奨し、Cypressもtest independenceを重視します。メールアドレスも同じ扱いが必要です。
cookieを消しても外部mailboxやtoken validityは初期化されません。
典型的なcollision
| Collision | False pass | False fail |
|---|---|---|
| 2 signup | AがBのmailを使う | messageが消費済み |
| 2 OTP | 任意codeをaccept | resendで相手code無効 |
| 2 reset | wrong linkで別account変更 | token superseded |
| global cleanup | inbox clean | 別workerのevidence消失 |
isolation unitを決める
- 1
可能なら1 test 1 address
最も説明しやすい境界です。
- 2
worker共有は内部serial時だけ
並列ならまだ衝突します。
- 3
correlationを追加
test IDやtime windowを使います。
- 4
teardownをlocalに
自分のresourceだけcleanします。
toolよりarchitectureが先
manual QAなら新しい一時受信箱で十分なことがあります。unattended CIならprogrammatic toolingを使います。どちらでもactive scenario同士がmail auth stateを共有しないことが本質です。
recipientをfixtureとして扱い各scenarioが所有すると、parallel email testingの結果は大幅に予測しやすくなります。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。