unit-testing - Outlook 收件人测试 : always succeed/always bounce

Question

我正在编写 JUnit 测试，并希望拥有一个始终成功的 Outlook 电子邮件收件人，以及一个始终因无法送达而退回的邮件收件人。

对于“永远成功”，我认为 SMTP 相当于 NUL:会很有帮助。

(我不想使用我的真实电子邮件地址有两个原因:1)我不想每次有人运行测试台时都收到测试电子邮件 2)如果我的雇主我不想让回归测试开始失败决定取消我的职位和电子邮件地址。)

对于“始终反弹”，我想我可以使用 im.a.nut@mycompany.com，但我愿意接受一种更可靠的技术，如果 Nut 先生加入 MyCompany，该技术不会中断。

除了“始终退回”之外，如果您有任何关于如何以及在何处查找“系统无法送达”消息的想法，我将不胜感激。我应该使用测试电子邮件帐户吗？或者也许是一个模拟退回消息的模拟框架？

编辑:根据 http://www.oracle.com/technetwork/java/faq-135477.html#bounce ，退回消息是标准化的，但没有广泛实现。电子邮件地址验证独立于 JavaMail。下面是我如何回答最后一段中的问题。测试电子邮件帐户可能需要一些时间才能收到消息，而且我不想阻止不能保证送达的消息。 mock 可能更有意义。

Answer 1

使用模拟来验证响应的处理逻辑绝对是要走的路。孤立测试只能让您走到这一步——最终您需要编写某种形式的集成测试，在网络上与邮件服务器进行通信，以验证您为单元测试所做的假设。

过去，我曾让 IT 部门使用仅限内部开发的邮件服务器启动虚拟机。此邮件服务器不直接连接到 Internet，但如果需要，可以通过公司邮件服务器路由。

拥有自己的域 Controller /邮件服务器可以让开发人员更好地控制通常不允许通过公司网络使用的功能。

关于处理不同类型的响应，我有一个项目需要测试不同类型的 session 邀请响应。我们为不同的电子邮件地址配置了服务器端规则，以便某些精心制作的主题或正文会自动响应接受、拒绝等。服务器端规则设置简单——只需以该用户身份登录(这是假域 Controller 派上用场)打开 Outlook 并配置规则。可以将更复杂的规则配置为 Exchange "Event Sink" 的一部分。 .

尽管如此，正如前面所建议的，您应该努力将响应的处理与发送操作分开。通过这种方式，您可以在没有环境开销的情况下测试处理。