Outlook 收件人测试：总是成功/总是退回
我正在编写 JUnit 测试，希望有一个始终会成功的 Outlook 电子邮件收件人和一个始终会因无法送达而退回的不同电子邮件收件人。
对于“总是成功”，我认为 SMTP 等价的 NUL: 会有所帮助。
（我不想使用我的真实电子邮件地址有两个原因：1）我不想每次有人运行测试床时都会收到测试电子邮件，2）如果我的雇主，我不希望回归测试开始失败决定消除我的职位和电子邮件地址。）
对于“总是退回”，我想我可以使用 [电子邮件受保护]，但愿意接受更可靠的技术，如果 Nut 先生加入 MyCompany，这种技术也不会被破坏。
除了“总是退回”之外，我还希望了解如何以及在何处查找“系统无法送达”消息的任何想法。我应该使用测试电子邮件帐户吗？或者也许是一个模拟框架来模拟退回消息？
编辑：根据 http://www.oracle.com/technetwork/ java/faq-135477.html#bounce，退回消息已标准化，但尚未广泛实施。电子邮件地址验证独立于 JavaMail。这是我回答上一段中的问题的方式。测试电子邮件帐户可能需要一些时间才能收到邮件，并且我不想阻止无法保证送达的邮件。嘲笑可能更有意义。
I am writing JUnit tests and would like to have an Outlook email recipient that will always succeed and a different one that will always bounce as undeliverable.
For the "always succeed," I think that the SMTP equivalent of NUL: would be helpful.
(I do not want to use my real email address for two reasons: 1) I don't want to get a test email every time someone runs the test bed and 2) I do not want to have regression tests start failing if my employer decides to eliminate my position and email address.)
For the "always bounce," I suppose I could use [email protected], but would be open to a more reliable technique that would not break if Mr. Nut joined MyCompany.
Along with "always bounce," I would appreciate any thoughts about how and where to look for the "System Undeliverable" messages. Should I use a test email account? Or perhaps a mocking framework to mock the bounce message?
EDIT: According to http://www.oracle.com/technetwork/java/faq-135477.html#bounce, the bounce message is standardized but not widely implemented. The email address validation is independent of JavaMail. Here's how I'd answer the questions in the last paragraph. A test email account might take some time before it gets the message, and I don't want to block on a message that is not guaranteed to be delivered. Mocking might make more sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用模拟来验证响应的处理逻辑绝对是可行的方法。孤立的测试只能让您到目前为止——最终您将需要编写某种形式的集成测试，通过网络与邮件服务器进行通信，以便验证您为单元测试所做的假设。
过去，我让 IT 部门启动了一台仅包含内部开发邮件服务器的虚拟机。该邮件服务器不直接连接到互联网，但如果需要，则通过公司邮件服务器进行路由。
拥有自己的域控制器/邮件服务器可以让开发人员更好地控制通常不允许通过公司网络使用的功能。
关于处理不同类型的响应，我有一个项目，我们需要测试会议邀请的不同类型的响应。我们为不同的电子邮件地址配置了服务器端规则，以便某些精心设计的主题或正文会自动响应接受、拒绝等。服务器端规则的设置很简单——只需以该用户身份登录即可（这是假域控制器派上用场）打开 Outlook 并配置规则。可以将更复杂的规则配置为 Exchange“事件接收器” 的一部分。
尽管如此，正如之前所建议的，您应该努力将响应的处理与发送操作分开。通过这种方式，您可以测试处理过程，而无需环境开销。
Using mocks to validate processing logic of responses is definitely the way to go. Testing in isolation can only get you so far -- eventually you will need to write some form of integration test that communicates on the network to a mail server in order to validate the assumptions you've made for the unit tests.
In the past, I've had IT spin up a virtual machine with internal development only mail server. This mail server does not connect to the internet directly, but if needed routes through the company mail server.
Having your own domain controller / mail server provides you, the developer, greater control over features that would normally not be permitted via the corporate network.
Regarding handling different types of responses, I had a project where we needed to test different types of responses for meeting invites. We configured server-side rules for different email addresses so that certain crafted subject or body would auto-respond with acceptance, reject, etc. A server-side rule is simple to set up -- simply logon as that user (this is where the fake domain controller comes in handy) open outlook and configure a rule. More complex rules can be configured as part of an Exchange "Event Sink".
Still, as earlier suggested you should strive to separate the processing of the response from the sending action. In this fashion you can test the processing without the environment overhead.