observation latencyとdelivery latencyを分ける
メールテストのPollingとRealtime：delivery保証ではなく待機戦略として選ぶ
Pollingとeventは受信後の観測方法を変えるだけで、sender、queue、SMTP deliveryの時間を短縮するものではありません。
Email timeoutの原因はsender delay、delivery delay、realtime event loss、matcher bugのどれかかもしれません。Pollingとrealtimeが解くのは観測だけです。期待messageとdeadlineを先に定義し、その後で観測方法を選びます。
2つの観測戦略
| Property | Polling | Realtime |
|---|---|---|
| Mechanism | 定期query | event reaction |
| Complexity | interval/timeout | connection/reconnect |
| Load | empty checks | less empty checking |
| Failure | bad timeout | missed event |
| Fallback | deadlineまで自然にretry | reconciliationが有効 |
predicateとdeadlineで待つ
- 1
message predicateを定義
recipient、sender、subject、time window。
- 2
deadline設定
infinite loop禁止。
- 3
matchまでobserve
poll/event/hybridで共通matcherを使えます。
- 4
layer別にfail
no delivery、wrong message、event failureを区別します。
fixed sleepよりretryable wait
Playwrightのexpect.pollやauto-retrying assertions、Cypress retry-abilityは、固定sleepよりcondition-based waitの方が扱いやすいことを示します。
固定sleepは速い時に無駄で、少し遅いだけでfalse failureになります。
RealtimeはSMTPをrealtimeにしない
receiverがmessageを保存した直後にeventを出せても、upstream senderやqueueを早くすることはできません。
Pollingかrealtimeかより、expected message、finite deadline、layer-specific diagnosticsを持つことが重要です。
手動メールQA用のクリーンな受信先が必要ですか？
MailOnceで、個人の受信箱をテストデータとして使わずに、登録、OTP、マジックリンク、パスワード再設定、通知メールを確認できます。
使い捨てメールを作成参考資料と追加情報
テスト指針の根拠として使用したセキュリティ資料とテストランナーの一次ドキュメントです。
次のテストへ
同じメールテスト領域にある次の境界を確認します。