# JUnit 最佳實踐指南 > 原文： [https://howtodoinjava.com/best-practices/unit-testing-best-practices-junit-reference-guide/](https://howtodoinjava.com/best-practices/unit-testing-best-practices-junit-reference-guide/) 我假設您了解 [JUnit](http://junit.org/junit4/ "junit") 的基礎知識。 如果您沒有基礎知識，請首先閱讀（已針對 JUnit 5 更新）。 現在，我們將介紹在編寫測試用例時必須考慮的 **junit [最佳實踐](//howtodoinjava.com/java-best-practices/ "best practices")**。 > 編寫糟糕的單元測試非常容易，這會給項目增加很少的價值，同時又會天文數字地增加代碼更改的成本。 ```java Table of Contents Unit testing is not about finding bugs Tips for writing great unit tests Test only one code unit at a time Don’t make unnecessary assertions Make each test independent to all the others Mock out all external services and state Don’t unit-test configuration settings Name your unit tests clearly and consistently Write tests for methods that have the fewest dependencies first, and work your way up All methods, regardless of visibility, should have appropriate unit tests Aim for each unit test method to perform exactly one assertion Create unit tests that target exceptions Use the most appropriate assertion methods. Put assertion parameters in the proper order Ensure that test code is separated from production code Do not print anything out in unit tests Do not use static members in a test class Do not write your own catch blocks that exist only to fail a test Do not rely on indirect testing Integrate Testcases with build script Do not skip unit tests Capture results using the XML formatter Summary ``` 在編程中，“[**單元測試**](https://en.wikipedia.org/wiki/Unit_testing "Unit testing")是一種測試源代碼的各個單元以確定它們是否適合使用的方法。” 現在，這個源代碼單元可以在不同的情況下使用。 例如：在[過程編程](https://en.wikipedia.org/wiki/Procedural_programming "Procedural programming")中，一個單元可以是一個完整的模塊，但更常見的是一個單獨的函數或過程。 在[面向對象編程](https://en.wikipedia.org/wiki/Object-oriented_programming "Object-oriented_programming")中，一個單元通常是一個完整的接口，例如一個類，但可以是一個單獨的方法。 直觀上，應該將一個單元視為應用中最小的可測試部分。 ## 單元測試不是尋找回歸錯誤 好吧，了解單元測試的動機很重要。 **單元測試不是查找應用范圍的錯誤或檢測[回歸](https://en.wikipedia.org/wiki/Regression_testing "Regression testing")缺陷的有效方法。 根據定義，單元測試將分別檢查代碼的每個單元。** 但是，當您的應用實際運行時，所有這些單元都必須協同工作，并且整個過程比獨立測試部分的總和更加復雜和微妙。 證明 X 和 Y 組件都可以獨立工作，并不表示它們相互兼容或配置正確。 **因此，如果您要查找回歸錯誤，則實際上一起運行整個應用**會更有效，因為它將在生產環境中運行，就像[手動測試](https://en.wikipedia.org/wiki/Manual_testing "Manual testing") 。 如果您將這種測試自動化以檢測將來發生的破損，則稱為[集成測試](https://en.wikipedia.org/wiki/Integration_testing "Integration testing")，通常使用與單元測試不同的技術。 > “從本質上講，單元測試應該被視為設計過程的一部分，因為它是 TDD（[**測試驅動開發**](https://en.wikipedia.org/wiki/Test-driven_development "Test-driven_development")）中的一部分。” 這應該用于支持設計過程，以便設計人員可以識別系統中的每個最小模塊并分別進行測試。 ## 編寫出色的單元測試的提示 #### 1.一次僅測試一個代碼單元 首先，也許是最重要的。 當我們嘗試測試代碼單元時，該單元可能有多個用例。 我們應該始終在單獨的測試用例中測試每個用例。 例如，如果我們為一個函數編寫測試用例，該函數應該具有兩個參數，并且在進行一些處理后應返回一個值，那么不同的用例可能是： 1. *第一個參數可以為空。 它應該拋出無效的參數異常。* 2. *第二個參數可以為空。 它應該拋出無效的參數異常。* 3. *兩者都可以為空。 它應該拋出無效的參數異常。* 4. *最后，測試功能的有效輸出。 它應該返回有效的預定輸出。* 當您進行了一些代碼更改或重構，然后測試功能沒有損壞時，這將很有幫助，運行測試用例就足夠了。 同樣，如果您更改任何行為，則需要更改單個或最少數量的測試用例。 #### 2.不要做出不必要的斷言 請記住，單元測試是某種行為應該如何工作的設計規范，而不是對代碼碰巧所做的所有事情的觀察列表。 不要試圖斷言所有事情都只專注于要測試的內容，否則，由于一個原因，您最終將導致多個測試用例失敗，這無助于實現任何目標。 #### 3.使每個測試獨立于其他所有測試 不要制作單元測試用例鏈。 這將阻止您確定測試用例失敗的根本原因，并且您將不得不調試代碼。 同樣，它會創建依賴關系，這意味著如果您必須更改一個測試用例，那么您就不必要在多個測試用例中進行更改。 嘗試對所有測試用例使用[**`@Before`**](http://junit.sourceforge.net/javadoc/org/junit/Before.html "Junit @Before annotation")和[**`@After`**](http://junit.sourceforge.net/javadoc/org/junit/After.html "junit @After annotation")方法。 如果您需要多種支持`@Before`或`@After`中的不同測試用例的方法，請考慮創建新的`Test`類。 #### 4.模擬所有外部服務和狀態 否則，這些外部服務中的行為會與多個測試重疊，并且狀態數據意味著不同的單元測試會影響彼此的結果。 如果您必須按照特定的順序運行測試，或者只有在數據庫或網絡連接處于活動狀態時才能運行，則您肯定走錯了路。 **另外，這很重要，因為您不希望調試由于某些外部系統中的錯誤而實際失敗的測試用例。** （順便說一句，有時您的架構可能意味著您的代碼在單元測試期間會觸及靜態變量。如果可以，請避免這樣做，但如果不能這樣做，請至少確保每個測試在運行之前將相關的靜態操作重置為已知狀態。 ） #### 5.不進行單元測試配置設置 根據定義，您的配置設置不是任何代碼單元的一部分（這就是為什么您將設置提取到某些屬性文件中的原因）。 即使您可以編寫用于檢查配置的單元測試，也可以只編寫一個或兩個測試用例，以驗證配置加載代碼是否正常工作，僅此而已。 在每個單獨的測試用例中測試所有配置設置僅證明了一件事：“ **您知道如何復制和粘貼**。” #### 6.清晰一致地命名您的單元測試 好吧，這可能是最重要的一點，要記住并保持關注。 您必須根據測試案例的實際用途和測試來命名它們。 使用類名和方法名作為測試用例名稱的測試用例命名約定從來都不是一個好主意。 每次更改方法名稱或類名稱時，您最終也會更新很多測試用例。 但是，如果您的測試用例名稱是邏輯的，即基于操作，則幾乎不需要修改，因為大多數應用邏輯將保持不變。 例如。 測試用例名稱應類似于： ```java 1) TestCreateEmployee_NullId_ShouldThrowException 2) TestCreateEmployee_NegativeId_ShouldThrowException 3) TestCreateEmployee_DuplicateId_ShouldThrowException 4) TestCreateEmployee_ValidId_ShouldPass ``` #### 7.首先對依賴關系最少的方法編寫測試，然后逐步進行 該原則表明，如果要測試`Employee`模塊，則應該首先測試`Employee`模塊的創建，因為它對外部測試用例的依賴項最小。 一旦完成，就開始編寫`Employee`修改的測試用例，因為它們需要一些雇員在數據庫中。 要在數據庫中擁有一些員工，您的創建員工測試用例必須先通過，然后才能繼續。 這樣，如果員工創建邏輯中存在一些錯誤，則可以更早地發現它。 #### 8.所有方法，無論是否可見，都應進行適當的單元測試 好吧，這確實是有爭議的。 您需要查找代碼中最關鍵的部分，并且應該對其進行測試，而不必擔心它們是否是私有的。 這些方法可以具有從一到兩個類調用的某些關鍵算法，但是它們起著重要的作用。 您想確保它們按預期工作。 #### 9.針對每種單元測試方法，精確執行一個斷言 即使這不是經驗法則，您也應該嘗試在一個測試用例中僅測試一件事。 不要在單個測試用例中使用斷言來測試多個事物。 這樣，如果某個測試用例失敗，則可以確切地知道出了什么問題。 #### 10.創建針對異常的單元測試 如果某些測試用例希望從應用中拋出[**異常**](//howtodoinjava.com/best-practices/best-practices-for-for-exception-handling/ "Best practices for Exception handling")，請使用“`Expected`”屬性。 嘗試避免在`catch`塊中捕獲異常，并使用`fail`或`asset`方法結束測試。 ```java @Test(expected=SomeDomainSpecificException.SubException.class) ``` #### 11.使用最合適的斷言方法 每個測試用例都可以使用許多斷言方法。 運用最適當的理由和思想。 他們在那里是有目的的。 尊敬他們。 #### 12.以正確的順序放置斷言參數 斷言方法通常采用兩個參數。 一個是期望值，第二個是原始值。 根據需要依次傳遞它們。 如果出現問題，這將有助于正確的消息解析。 #### 13.確保測試代碼與生產代碼分開 在您的構建腳本中，確保測試代碼未與實際源代碼一起部署。 這浪費了資源。 #### 14.不要在單元測試中打印任何內容 如果您正確地遵循了所有準則，那么您將不需要在測試用例中添加任何打印語句。 如果您想擁有一個，請重新訪問您的測試用例，您做錯了什么。 #### 15.不要在測試類中使用靜態成員。 如果您已經使用過，則針對每個測試用例重新初始化 我們已經說過，每個測試用例都應該彼此獨立，因此永遠不需要靜態數據成員。 但是，如果您在緊急情況下需要任何幫助，請記住在執行每個測試用例之前將其重新初始化為初始值。 #### 16.不要寫自己的只能使測試失敗的`catch`塊 如果測試代碼中的任何方法引發某些異常，則不要編寫`catch`塊只是為了捕獲異常并使測試用例失敗。 而是在測試用例聲明本身中使用`throws Exception`語句。 我將建議使用`Exception`類，并且不要使用`Exception`的特定子類。 這也將增加測試范圍。 #### 17.不要依賴間接測試 不要假定特定的測試用例也會測試另一種情況。 這增加了歧義。 而是為每種情況編寫另一個測試用例。 #### 18.將測試用例與構建腳本集成 最好將測試用例與構建腳本集成在一起，以使其在生產環境中自動執行。 這提高了應用以及測試設置的可靠性。 #### 19.不要跳過單元測試 如果某些測試用例現在無效，則將其從源代碼中刪除。 不要使用[**`@Ignore`**](http://junit.sourceforge.net/javadoc/org/junit/Ignore.html "Junit @Ignore annotation")或`svn.test.skip`來跳過它們的執行。 在源代碼中包含無效的測試用例不會幫助任何人。 #### 20.使用 XML 格式器捕獲結果 這是感覺良好的因素。 它絕對不會帶來直接的好處，但是可以使運行單元測試變得有趣和有趣。 您可以將 JUnit 與 ant 構建腳本集成，并生成測試用例，并使用一些顏色編碼以 XML 格式運行報告。 遵循也是一種很好的做法。 ## 總結 毫無疑問，單元測試可以顯著提高項目質量。 我們這個行業中的許多學者聲稱，任何單元測試總比沒有好，但是我不同意：測試套件可以成為一項重要資產，但是不良套件可以成為負擔不起的同樣巨大的負擔。 這取決于這些測試的質量，這似乎取決于其開發人員對單元測試的目標和原理的理解程度。 如果您理解上述準則，并嘗試在下一組測試用例中實現其中的大多數準則，那么您一定會感到與眾不同。 請讓我知道您的想法。 學習愉快！