我通常会说任何一段代码，无论它做什么，特别是如果它在生产环境中运行应该进行测试。 但是，我一直想知道动态电子邮件内容是否应该是一个例外。它经常变化，并且通常很难正确和全面地测试，我不知道它是否值得。通常情况下，单元测试的内容无论如何都会被复制/粘贴（我知道这并不理想，但仍然会发生），所以除了告诉我们是否会严重爆炸之外，它并没有真正带来任何真正的好处，而且只是尝试发送电子邮件（不验证副本）的简单单元测试应该可以解决这个问题。
我希望从其他开发者那里得到一些意见。让我知道你的想法。是否单元测试电子邮件内容？
编辑： 澄清一下，我们已经对实际发送电子邮件进行了单独的单元/集成测试，这个问题指的是仅测试电子邮件的内容。目前我们只对动态内容进行单元测试，模板文本不在点击测试之外。
【问题讨论】：
标签： unit-testing email
你应该总是测试所有东西，是的，但你不能总是单元测试所有东西。在这种情况下，尝试验证电子邮件模板是否已正确生成在集成和用户验收测试中可能会更好。
但是，您可以对您的程序如何构建电子邮件模板进行单元测试，这是我建议您采用的方法。
构建一个用于填充电子邮件模板的 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);
只要方法是在接口或虚拟（并且不是静态的）中定义的，您就可以模拟您的代码在适当的时间调用到适当的模板构建器中的帮助程序类和单元测试。然后，您可以将拼写和格式以及其他内容推送到用户验收测试，并认为您的工作已经完成。
【讨论】：
我会添加一个单元测试来验证内容是否可以从模板（或其他动态源）放置在电子邮件中。该内容可以特定于此单元测试，例如“这是发给##USERNAME## 的测试电子邮件”或类似内容。如果模板发生变化，我不会用新的模板信息更新您的单元测试。
【讨论】：
我看到你想在这里测试两个不同的东西。测试生成的电子邮件内容就是其中之一，您应该能够重构您的代码，以便您可以对这部分进行单元测试。您可以编写一个仅处理电子邮件生成的函数或类，然后针对您感兴趣的不同输入围绕它编写单元测试。
如果电子邮件内容是您的代码的一部分，您应该围绕它进行某种测试。但也许您需要更多的完整性检查，而不是验证电子邮件内容是否完全匹配“恭喜{NAME}，您刚刚中了尼日利亚彩票......”。也许只是检查内容是否超过了一定的大小阈值，并且在正文中的某处包含收件人的姓名（或插入的任何动态内容）？
第二件事是测试邮件发送机制。这不是严格意义上的单元测试。我认为这是一个功能或集成测试。如果您已经有一个 QA 团队或流程来处理这种类型的大规模测试，那么您可能可以放心地使用它。如果没有，编写一个小型 stub SMTP 服务器来接受传入的邮件并将其作为功能测试套件的一部分运行并不难。 SMTP 是一个非常简单的协议，您只需要执行六个左右的命令即可接收邮件消息。我在大约一天前使用 Ruby 写了一篇。您需要能够重新配置您的应用使用的 SMTP 主机和端口，以便您可以设置一个用于测试，另一个用于生产。
【讨论】：
我的基本规则是：如果它影响应用程序的功能，请对其进行测试。 （是的，这是一个定义相当松散的规则。）
因此，我注意到网站发送的许多电子邮件都与用户激活类似。在这些情况下，我不会测试电子邮件本身的内容（那是内容，而不是功能），但我会验证它是否发送了正确的激活 URL。
我会将其扩展到任何由代码生成的动态电子邮件内容，而不是硬编码字符串消息的数据。
【讨论】：
当涉及到与您建议的系统类似的测试系统时，我的观点是您正在测试一个完整的系统，而不是一个逻辑代码块。我会编写单元测试来测试系统中较小的代码单元和一些连接的部分，并使用功能测试与用户一起测试整个系统。
【讨论】：
单元测试可确保您的所有合并代码在有限集时都能正常工作，或者如果合并机制是动态的，则合并机制也能正常工作。以及模板文本是否适合合并文档的测试是有意义的。
在此之后测试每个模板不应该真正增加任何价值，但确实增加了一堆工作。
【讨论】：