Question

我通常会说一句代码，无论它做什么，特别是如果它在生产环境中运行应该进行测试。不过，我一直在想，动态电子邮件内容应该是个例外。它经常变化，通常是一个痛苦，正确和充分测试，我不知道它是否值得。通常情况下，单元测试的内容是复制/粘贴的（我知道这不是理想的，但仍然会发生），所以除了告诉我们某些东西是否会严重爆炸之外，它并没有真正带来任何真正的好处，并且简单的单元测试只是试图发送电子邮件（不验证副本）应该照顾。

我希望得到其他开发者的一些意见。让我知道你的想法。单元测试电子邮件内容与否？

编辑：为了澄清，我们已经对实际发送电子邮件进行了单独的单元/集成测试，这个问题仅指测试电子邮件的内容。目前我们只测试动态内容，模板文本不是点击测试。

Answer 1

你应该总是测试一切，是的，但你不能总是单位测试一切。在这种情况下，尝试验证电子邮件模板是否已正确生成在集成和用户验收测试中可能会更好。

然而，您可以对您的程序如何构建电子邮件模板进行单元测试，这是我建议您使用的路线。

构建一个API来填充电子邮件模板，这是一个帮助类，其方法如下：

// using C# syntax returning strings for the example -- you could just as easily return
// System.Net.Mail.MailMessage or javax.mail.Message instead
string BuildPasswordChangeTemplate(string username, string newPassword, string email);
string BuildErrorTeplate(string methodName, string serviceName, Exception e);

只要方法在接口或虚拟中定义（并且不是静态的），就可以在适当的时候模拟代码调用相应模板构建器的辅助类和单元测试。然后，您可以将拼写和格式以及其他内容推送到用户验收测试并考虑您的工作已完成。

Answer 2

我会添加一个单元测试，用于验证内容是否可以放在模板（或其他动态源）的电子邮件中。该内容可以特定于此单元测试，例如“这是对## USERNAME ##的测试电子邮件”或类似内容。如果模板发生更改，我将不会使用新模板信息更新您的单元测试。

Answer 3

我在这里看到了你想要测试的两个不同的东西。测试生成的电子邮件内容是一个，您应该能够重构代码，以便您可以对该部分进行单元测试。您可以编写一个只处理电子邮件生成的函数或类，然后针对您感兴趣的不同输入编写单元测试。

如果电子邮件内容是您的代码的一部分，您应该对其进行某种测试。但也许你想要更多的理智检查而不是验证电子邮件内容与“祝贺{NAME}完全匹配，你刚刚赢得尼日利亚彩票......”。也许只是检查内容是否超过特定大小阈值，并且它包含正文中某处的收件人姓名（或插入的任何动态内容）？

第二件事是测试邮件发送机器。这不是严格的单元测试;我认为是功能测试或集成测试。如果你有一个QA团队或流程来处理这种类型的大规模测试，你可以安全地对此进行讨论。如果没有，编写一个小的存根SMTP服务器来接受传入的邮件并将其作为功能测试套件的一部分运行并不困难。 SMTP是一个非常简单的协议，您只需要实现六个左右的命令来接受邮件消息。我刚刚写了一篇关于一天使用Ruby的文章。您需要能够重新配置应用程序使用的SMTP主机和端口，以便您可以设置一个用于测试，另一个用于生产。

Answer 4

我的基本规则是：如果它影响应用程序的功能，请对其进行测试。（是的，这是一个非常松散定义的规则。）

因此，我注意到网站发送的很多电子邮件都是用户激活等内容。在这些情况下，我不会测试电子邮件本身的内容（这是内容，而不是功能），但我将验证它是否发送了正确的激活URL。

我会将其扩展到由代码生成的任何动态电子邮件内容，而不是硬编码的字符串消息。

Answer 5

当涉及到与您建议的系统类似的测试系统时，我的观点是您正在测试完整系统而不是逻辑代码块。我会编写单元测试来测试系统中较小的代码单元和一些连接的部分，并使用用户的功能测试来测试整个系统。

Answer 6

单元测试以确保您的所有合并代码在有限集合时起作用，或者如果合并机制是动态的则合并机制。以及模板文本使其合并文档的测试是有意义的。

在测试之后，每个模板不应该真正添加任何值，但确实添加了许多工作。

单元测试电子邮件内容

6 个答案: