返回开发者与 QA
观察延迟与投递延迟是两条时间线
邮件测试里的 Polling 与 Realtime：选择等待策略，而不是伪造投递保证
Polling和event只决定测试如何发现新邮件，并不能控制sender、queue或SMTP真正什么时候完成投递。
约 8 分钟
Email timeout可能来自sender延迟、投递延迟、realtime event丢失，或者message matcher错误。Polling与realtime只解决“怎么观察”。测试应该先定义期待的message和deadline，然后才决定使用哪种观察机制。
两种观察策略
| 属性 | Polling | Realtime |
|---|---|---|
| 机制 | 周期query | 响应event |
| 复杂度 | interval/timeout | connection/reconnect |
| 负载 | 空检查 | 空检查较少 |
| 失败 | timeout设置差 | event丢失 |
| Fallback | 自然retry到deadline | 适合加reconciliation |
围绕predicate与deadline设计
- 1
定义message
recipient、sender、subject、time window。
- 2
定义deadline
不要无限loop。
- 3
观察直到match
poll/event/hybrid可以共用matcher。
- 4
按层报告失败
区分未投递、错误message和realtime failure。
Retryable wait优于固定sleep
Playwright的expect.poll和auto-retrying assertions、Cypress的retry-ability都体现了同一原则：等待条件成立，而不是盲目sleep。
固定sleep在快速场景浪费时间，在稍慢场景制造false failure。
Realtime不会让SMTP变成实时
receiver存储message后可以马上发event，但它不能让upstream sender或queue更早投递。
Polling还是realtime并不是核心；核心是明确expected message、有限deadline，以及能区分sender、delivery、event和matcher问题的诊断。
需要一个干净的收件地址做手工邮件 QA？
使用 MailOnce 检查真实的注册、OTP、魔法链接、密码重置和通知邮件，无需把个人邮箱放进测试数据。
创建临时邮箱来源与延伸阅读
用于支撑测试建议的安全资料和测试运行器一手文档。
继续测试
继续查看同一邮件测试问题空间中的下一个边界。