Outlook收件人测试：永远成功/总是反弹

如何解决Outlook收件人测试：永远成功/总是反弹

| 我正在编写JUnit测试，希望有一个将始终成功的Outlook电子邮件收件人和另一个将始终无法发送的邮件收件人。 对于“总是成功”，我认为等同于

NUL:

的SMTP会有所帮助。 （我不想使用真实的电子邮件地址，原因有两个：1）我不想每次有人运行测试床时都收到测试电子邮件； 2）如果我的回归测试开始失败，我不想雇主决定取消我的职位和电子邮件地址。） 对于“总是弹跳”，我想我可以使用[e-mail]，但可以接受更可靠的技术，如果Nut先生加入MyCompany，这将不会失败。 除了“总是跳动”外，对于任何关于如何以及在何处查找“系统无法交付的”消息的想法，我将不胜感激。我应该使用测试电子邮件帐户吗？还是一个模拟框架来模拟退回消息？ 编辑：根据http://www.oracle.com/technetwork/java/faq-135477.html#bounce，退信消息是标准化的，但并未得到广泛实施。电子邮件地址验证独立于JavaMail。这是我如何回答上一段中的问题。测试电子邮件帐户可能需要一些时间才能收到消息，并且我不想阻止无法保证传递的消息。模拟可能更有意义。     

解决方法

使用模拟来验证响应的处理逻辑绝对是必经之路。隔离测试只能使您步入正轨-最终，您将需要编写某种形式的集成测试，以通过网络与邮件服务器通信，以验证您对单元测试所做的假设。 过去，我曾让IT部门使用仅内部开发的邮件服务器来启动虚拟机。该邮件服务器不直接连接到Internet，而是在需要时通过公司邮件服务器路由。 拥有自己的域控制器/邮件服务器为开发人员提供了对通常无法通过公司网络允许的功能的更好控制。 关于处理不同类型的响应，我有一个项目，我们需要测试会议邀请的不同类型的响应。我们为不同的电子邮件地址配置了服务器端规则，以便某些精心设计的主题或正文将自动接受，拒绝等响应。服务器端规则很容易设置-只需以该用户身份登录（伪造的域控制器派上用场）打开Outlook并配置规则。可以将更复杂的规则配置为Exchange“事件接收器”的一部分。 仍然，如前所述，您应努力将响应的处理与发送操作分开。通过这种方式，您可以在没有环境开销的情况下测试处理。