raj*_*ah9 5 email outlook junit unit-testing mocking
我正在编写JUnit测试,并希望有一个Outlook电子邮件收件人,这个收件人将永远成功,而另一个收件人总是会因为无法投递而反弹.
对于"总是成功",我认为相当于SMTP NUL:会有所帮助.
(我不想使用我的真实电子邮件地址有两个原因:1)我不希望每次有人运行测试床时都会收到测试电子邮件2)如果我的雇主,我不想让回归测试开始失败决定取消我的职位和电子邮件地址.)
对于"总是弹跳",我想我可以使用im.a.nut@mycompany.com,但是如果Nut先生加入MyCompany,那么对于一种更加可靠的技术是开放的.
随着"永远反弹",我将不胜感激任何关于如何以及在何处寻找"系统无法传送"消息的想法.我应该使用测试电子邮件帐户吗？或者也许是一个模拟反弹消息的模拟框架？
编辑:根据http://www.oracle.com/technetwork/java/faq-135477.html#bounce,退回邮件是标准化的,但没有广泛实施.电子邮件地址验证独立于JavaMail.这是我如何回答最后一段中的问题.测试电子邮件帐户可能需要一些时间才能收到消息,我不想阻止无法保证交付的消息.嘲弄可能更有意义.
使用模拟来验证响应的处理逻辑绝对是可行的方法。孤立的测试只能让您到目前为止——最终您将需要编写某种形式的集成测试，通过网络与邮件服务器进行通信，以便验证您为单元测试所做的假设。
过去，我让 IT 部门启动了一台仅包含内部开发邮件服务器的虚拟机。该邮件服务器不直接连接到互联网，但如果需要，则通过公司邮件服务器进行路由。
拥有自己的域控制器/邮件服务器可以让开发人员更好地控制通常不允许通过公司网络使用的功能。
关于处理不同类型的响应，我有一个项目，我们需要测试会议邀请的不同类型的响应。我们为不同的电子邮件地址配置了服务器端规则，以便某些精心设计的主题或正文会自动响应接受、拒绝等。服务器端规则的设置很简单——只需以该用户身份登录即可（这是假域控制器派上用场）打开 Outlook 并配置规则。更复杂的规则可以配置为Exchange“事件接收器”的一部分。
尽管如此，正如前面所建议的，您应该努力将响应的处理与发送操作分开。通过这种方式，您可以测试处理过程，而无需环境开销。
| 归档时间： |
|
| 查看次数： |
321 次 |
| 最近记录： |