答案。

问题的历史：

电子邮件通知测试的自动化随着通知系统的发展而变得相关（例如，注册、密码更改、提醒等）。最初，这些测试是手动执行的，并通过真实的电子邮件进行检查（在CI/CD中非常低效且不安全）。随后出现了专门的工具（MailHog、Mailtrap、假SMTP服务器），使自动化成为可能并且安全。

问题：

主要的复杂性与电子邮件是从系统"外部"发送的有关，意味着需要：a）拦截发送，b）确认邮件内容，c）检查发送的正确性（标题格式、附件存在、链接、国际化、与系统事件的正确匹配）。增加了交付速度、测试之间清理邮箱、处理SMTP错误等复杂性。

解决方案：

• 使用专门的邮件拦截服务：Mailtrap、MailHog，或者集成的假SMTP服务器，这些服务器不将邮件发送到真实邮箱，而是将其保留在测试"垃圾箱"中。

• 通过API框架或REST封装集成与这些工具的工作，实现邮件等待、关键邮件参数检查、附件验证、正确链接的检查。

• 为测试生成唯一的电子邮件地址，隔离测试数据（例如，使用测试域）并在每次自动测试运行之前清理邮箱。

• 检查不仅邮件正文，还检查其中链接的可用性、从不同SMTP发送、不同地区和格式的正确显示。

关键特性：

• 使用"假"电子邮件地址、SMTP拦截器。
• 检查邮件内容、链接、头信息、附件。
• 使用API在测试前后清理/检查邮箱。

有陷阱的问题。

是否可以通过将邮件发送到普通的gmail/yandex邮箱并通过IMAP检查来测试电子邮件通知？

不可以，虽然很多人这样做，但这种方法不可靠（依赖外部电子邮件服务的运行、垃圾邮件过滤器、测试之间没有隔离、清理邮箱的复杂性，不保证交付）。

仅检查邮件是否到达是否足够？

不够，需要验证主体、附件、必要链接的存在、语言模板的正确性、头信息（发件人/收件人/主题）的匹配、mime结构的正确性。

在测试中可以不清理假收件箱吗？没什么大不了的？

不可以！如果不清理收件箱，测试之间会迅速混淆，找出bug将变得不可能。场景将"看到"其他人的邮件，测试将变得无效。

常见错误和反模式

• 使用不在CI/CD中的真实邮箱，没有隔离。
• 仅检查邮件到达的事实，而不检查内容和附件。
• 在测试之间缺乏清理收件箱。

生活中的例子

消极案例

通过测试gmail建立电子邮件测试，通过IMAP登录，只检查"是否收到了一些东西"。邮件经常进入垃圾邮件，部分邮件未送达，启动并行测试后在同一个收件箱中分析邮件变得不可能。

优点：

• 快速启动通知检查，无需单独的基础设施。

缺点：

• 没有隔离：他人的邮件干扰分析。
• 由于外部邮件问题，测试随机失败。
• 不验证附件、链接、模板。

积极案例

引入Mailtrap，为每个测试用例分配唯一的收件箱，实现自动清理、内容和附件验证、等待时间检查、语言检查。

优点：

• 可靠的自动化检查所有电子邮件通知的细节。
• 快速、隔离的测试，无外部依赖。

缺点：

• 导入基础设施（假SMTP、与API集成）需要时间。