【问题标题】:Outlook Recipient test: always succeed / always bounceOutlook 收件人测试:总是成功/总是退回
【发布时间】:2011-09-01 22:02:26
【问题描述】:

我正在编写 JUnit 测试,并希望拥有一个始终成功的 Outlook 电子邮件收件人和一个始终无法投递的电子邮件收件人。

对于“总是成功”,我认为NUL: 的 SMTP 等效项会有所帮助。

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

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

除了“总是退回”之外,我将不胜感激有关如何以及在何处查找“系统无法投递”消息的任何想法。我应该使用测试电子邮件帐户吗?或者也许是一个模拟框架来模拟退回消息?


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

【问题讨论】:

  • @Bryanbcook 发布了关于使用模拟的出色答案。这似乎是反弹的正确方法。关于发送地址的任何想法总是会成功?

标签: unit-testing email junit outlook mocking


【解决方案1】:

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

过去,我让 IT 部门启动了一台仅用于内部开发邮件服务器的虚拟机。此邮件服务器不直接连接到互联网,但如果需要,通过公司邮件服务器路由。

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

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

不过,如前所述,您应该努力将响应处理与发送操作分开。通过这种方式,您可以在没有环境开销的情况下测试处理。

【讨论】:

  • 我赞同 bryanbcook 建议使用的模拟,并推荐使用 mockito.org
  • @bryanbcook,感谢您的编辑和 Exchange“事件接收器”的链接。我认为这将帮助我改变 SMTP 管道。
猜你喜欢
  • 1970-01-01
  • 2021-05-16
  • 1970-01-01
  • 2016-02-07
  • 2019-04-02
  • 1970-01-01
  • 1970-01-01
  • 2012-09-19
  • 2017-10-25
相关资源
最近更新 更多