我通常會說一段代碼，不管它做什麼，特別是如果它在生產環境中運行，應該進行測試。 但是，我一直在想，如果動態電子郵件內容應該是一個例外。它經常變化，通常是一個痛苦，正確和充分測試，我不知道它是否值得。通常情況下，單元測試的內容無論如何都是複製/粘貼的（我知道這並不理想，但是卻會發生），所以除了告訴我們是否會有嚴重的事情發生，並沒有真正的好處，簡單的單元測試只是試圖發送電子郵件（不驗證副本）應該照顧。單元測試電子郵件內容
我希望能從其他開發者那裏得到一些意見。讓我知道你的想法。單元測試郵件內容還是不是？
編輯： 爲了澄清，我們已經對實際發送的電子郵件進行了單獨的單元/集成測試，這個問題指的是測試電子郵件的內容。目前我們只測試動態內容，模板文本不在點擊測試之外。
你應該總是測試一切，是的，但你不能總是單元測試一切。在這種情況下，試圖驗證電子郵件模板是否已正確生成，可能會更好地進行集成和用戶驗收測試。
但是，您可以單元測試您的程序如何構建電子郵件模板，並且這是我建議您去的路線。
建立一個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主機並移植您的應用程序，以便您可以設置一個用於測試，另一個用於生產。
單元測試可確保您的所有合併代碼在有限集合的情況下工作，或者合併機制在動態時可以工作。以及模板文本對合並文檔的測試是合理的。
之後測試每個模板不應該真的添加任何值，但會增加一堆工作。