便利な共有資源が曖昧なtest stateになる
共有テストメールボックスがメールQAをflakyにする理由
人、retry、environment、parallel runが1つのmailbox stateを共有するとmessage ownershipが曖昧になります。
共有QA inboxは最初は効率的です。しかしstagingとproduction-like mailが混ざり、retryが古いmessageを拾い、CIが人の調査中のmailを消すようになると、どのscenarioがどのmessageを所有するか分からなくなります。
共有の便利さと信頼性
| Pattern | Convenience | Ambiguity |
|---|---|---|
| signup用1 inbox | provision不要 | どのmailがどのrunか |
| multi-env inbox | access簡単 | 正しいhost/template |
| manual+CI | same evidence | 誰がconsume/deleteしたか |
| retry共有 | fixture再作成不要 | old messageでpass |
mailboxはexternal state
PlaywrightとCypressがbrowser stateをcleanにしても、外部recipientがglobalならtest couplingは残ります。
特にOTPやresetでは新しいrequestがbackend validityを変えるため、単なるinbox clutterではありません。
ownershipを明示する
- 1
scenarioごとにaddress
最も明確なownershipです。
- 2
reuse時はserial
active runを1つにします。
- 3
environmentを分ける
host bugを隠さないようにします。
- 4
human investigationとautomationを分ける
調査中にCIが状態を変えないようにします。
shared passwordだけではfixtureではない
fixtureにはsetup、owner、expected state、teardownが必要です。皆がloginできるだけのmailboxはその契約を持ちません。
目的はaddress数を増やすことではなく、各messageのownershipを事実にすることです。ownershipが明確ならorderやretryの影響が減ります。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。