# 不良單元測試用例的 8 個跡象 > 原文： [https://howtodoinjava.com/best-practices/8-signs-of-bad-unit-test-cases/](https://howtodoinjava.com/best-practices/8-signs-of-bad-unit-test-cases/) 如果您從事軟件開發已有很長時間，那么您可以輕松地與單元測試的重要性聯系起來。 專家說，如果我們遵循這些[**最佳實踐來編寫單元測試**](//howtodoinjava.com/best-practices/unit-testing-best-practices-junit-reference-guide/ "Unit testing best practices : Junit Reference guide")，那么大多數錯誤都可以在單元測試階段本身捕獲，并最終傳遞給質量團隊。 “編寫糟糕的單元測試極其容易，這給項目增加了很少的價值，同時又天文數字地增加了代碼更改的成本。” 雖然，糟糕的單元測試是現實，并且每個進行代碼審查的人都偶爾（可能是定期）面對它。 那么，什么構成不良的測試案例呢？ 如何識別不良測試案例？ 在這篇文章中，我試圖確定 8 個這樣的跡象，這些跡象將為您提供微妙的提示，即一個特定的測試用例不好，需要進行更新。 ```java Table of Contents Test passes but not testing the actual feature Testing irrelevant things Testing multiple things in assertions Test accessing the testee using reflection Tests swallowing exceptions Test which depends on excessive setup Test compatible to only developer's machine Test filling log files with load of texts ```  8 個不良單元測試用例的跡象 讓我們一一看一下這些指針的含義： ## 1）測試通過但未測試實際功能 相信我，我在以前的項目中看到過這樣的測試用例，它們似乎在代碼中做了很多工作，但實際上它們什么也沒做。 他們正在向服務器發送請求，無論什么服務器響應，它們都在傳遞。 恐怖！ 通過嚴格的代碼審查，當心將此類測試用例放在您的代碼倉庫中。 一旦它們進入您的代碼庫，它們將成為您承擔責任，每次攜帶，構建和運行它們，但不增加任何價值。 ## 2）測試無關的東西 這是測試用例不好的另一個標志。 我已經看到開發人員檢查了多個不相關的事情，以便代碼可以執行某些操作，但不一定是正確的事情。 最好的方法是遵循單一責任原則，即一個單元測試用例只能測試一件事，僅此而已。 ## 3）測試斷言中的多個事物 這個似乎與上面的跡象相似，但事實并非如此。 在以前的符號中，測試正在測試不相關的事物，而在此符號中，此處是對一個正確的事物進行單元測試，但是在一個測試用例中測試了許多這樣的事物。 這再次違反了單一責任原則。 好吧，請注意，我不鼓勵在每個測試用例中使用單個斷言。 要測試單個實體，您可能需要使用多個斷言，并根據需要執行。 例如，一個 API 在帖子主體中采用一些參數并創建`Employee`對象并作為響應返回。 此`Employee`對象可以具有多個字段，例如名字，姓氏，地址等。編寫一個測試用例以僅驗證名字，然后編寫一個用于驗證姓氏和另一個用于地址的測試用例是代碼的重復性，而沒有任何值。 不要做 而是編寫一個用于創建員工的肯定測試用例，并驗證該單元測試中的所有字段。 在這種情況下，負測試用例應單獨編寫，僅做一件事和一個斷言。 例如，一個測試用例用于空白的名字，一個測試用例用于無效的名字，依此類推。 可以使用單個斷言來驗證所有此類否定測試用例，這些斷言可以期望[**響應中出現異常**](//howtodoinjava.com/junit/junit-testcases-which-expects-exception-on-runtime/ "Junit testcases which expects exception on runtime")。 ## 4）使用反射測試被測者的訪問 這真是太糟糕了。 嘗試將測試對象更改為需要的用戶。 在測試對象上進行代碼重構時會發生什么。 測試用例會爆炸。 請勿使用或允許使用。 ## 5）測試隱藏了異常 我得到了這些測試用例的應有份額。 在測試用例結束時，他們以小小的`catch`塊靜默地吞下了異常。 更糟糕的是，它們也不會發出失敗的警報。 異常是您的應用拋出的信號，以表明發生了某些不良情況，您必須對其進行調查。 您不應允許測試用例忽略這些信號。 每當您看到意外的異常時，請立即使測試用例失敗。 ## 6）測試取決于過多的設置 我不喜歡測試用例，它需要在開始測試實際事物之前發生很多事情。 這樣的場景可能像：促進在線會議的應用。 現在測試特定類型的用戶是否可以加入會議，以下是測試執行的步驟： * 創建用戶 * 設置用戶權限 * 創建會議 * 設置會議屬性 * 發布會議參加信息 * [測試]用戶參加會議 * 過關失敗 現在，在上述情況下，在驗證實際邏輯之前必須設置 5 個復雜的步驟。 對我來說，這不是一個很好的測試案例。 正確的測試系統至少要為此活動在系統中存在一個現有用戶。 在測試用例中，它將至少減少兩個步驟。 如果可以的話，他可以召開一些已經創建的會議，也可以使這個測試用例真正成為重點。 另一種使其正確的方法是使用模擬對象。 他們在那里是為了這個目的。 是嗎？ ## 7）測試僅兼容開發者的機器 這不是很廣為人知，但當新生寫的時候有時可見。 他們使用依賴于系統的文件路徑，環境變量或屬性來代替使用通用屬性/路徑或類似的東西。 提防他們。 ## 8）使用文本加載測試日志文件的填充 他們似乎并沒有在快樂的日子里制造問題。 但是，在下雨天的時候，它們通過在日志文件中放置沒有任何信息的不必要的文本來使人為難，并為試圖查找那些日志文件中隱藏的內容的調試器帶來了麻煩。 測試不是為了調試應用，因此不要放置調試日志種類語句。 一個通過/失敗的日志語句就足夠了。 相信我。 這些是我根據最近幾年的學習而得出的想法。 我不希望您在上述所有方面都同意我的觀點。 但是可能還有其他一些很酷的觀點。 但是我肯定會想討論您對主題的看法。 **祝您學習愉快！**