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