# 編寫好的單元測試的 FIRST 原則 > 原文： [https://howtodoinjava.com/best-practices/first-principles-for-good-tests/](https://howtodoinjava.com/best-practices/first-principles-for-good-tests/) 在解決現實問題的任何應用中，單元測試中都存在問題 – 是最不希望的事情。 [好的書面測試](//howtodoinjava.com/best-practices/unit-testing-best-practices-junit-reference-guide/)是資產，而不好的書面測試是您應用的負擔。 在本教程中，我們將學習**單元測試 FIRST 原則**，它可以使您的測試脫穎而出，并確保其收益超過成本。 ## 良好單元測試的首要原則 首字母縮寫詞 FIRST 表示以下測試功能： * [F]快速 * [I]隔離 * [R]可重復 * [S]自我驗證 * [T]及時 如果您在編寫單元測試時遵循這五個原則，那么您將擁有更健壯的單元測試，從而使應用代碼更穩定。 讓我們詳細了解這些 FIRST 原則。 #### 快速 **單元測試應該快速**，否則它們會減慢您的開發/部署時間，并且需要更長的時間才能通過或失敗。 通常，在足夠大的系統上，將有數千個單元測試 - 假設有 2000 個單元測試。 如果平均單元測試需要 200 毫秒才能運行（應該被認為是快速的），那么運行完整套件將需要 6.5 分鐘。 在此階段，6.5 分鐘的時間似乎并不長，但請想象一下，如果您一天在開發計算機上多次運行它們，將會消耗大量的生產時間。 想象一下，當向應用添加新功能時，這些測試的數量增加時，它將進一步增加測試執行時間。 您的單元測試套件的價值會降低，因為它們提供有關系統運行狀況的連續，全面和快速反饋的能力也會降低。 緩慢測試的主要原因之一是依賴關系，必須處理外部邪惡的必需品，例如數據庫，文件和網絡調用。 他們花費數千毫秒。 因此，要使套件快速運行，必須避免通過使用[模擬測試](https://howtodoinjava.com/library/mock-testing-using-powermock-with-junit-and-mockito/)創建這些依賴項。 #### 隔離 **永遠不要編寫依賴于其他測試用例的測試**。 無論您如何精心設計它們，總會有誤報的可能性。 更糟的是，您可能最終會花費更多的時間來確定鏈中的哪個測試導致了失敗。 在最佳情況下，您應該可以在任何時間以任何順序運行任何人的測試。 通過進行獨立的測試，可以輕松地使測試僅關注少量行為。 如果該測試失敗，您將確切知道出了什么問題以及出了什么地方。 無需調試代碼本身。 [SOLID 類設計原則](//howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/)的單一責任原則（SRP）指出，類應該小而單一。 這也可以應用于您的測試。 如果您的一種測試方法可能由于多種原因而失敗，請考慮將其拆分為單獨的測試。 #### 可重復 **可重復測試**每次運行都會產生相同的結果。 要完成可重復的測試，必須將它們與外部環境中的任何東西隔離開，而不是直接控制。 在這些情況下，請隨意使用模擬對象。 它們就是為此目的而設計的。 有時，您需要直接與外部環境影響進行交互，例如數據庫。 您需要設置一個私有沙箱，以避免與測試同時更改數據庫的其他開發人員發生沖突。 在這種情況下，您可以使用[內存數據庫](//howtodoinjava.com/hibernate/hibernate-4-using-in-memory-database-with-hibernate/)。 如果測試不可重復，那么您肯定會得到一些虛假的測試結果，并且您不能浪費時間去追逐幻象問題。 #### 自我驗證 測試必須是自我驗證的手段 – 每個測試都必須能夠確定預期的輸出與否。 它必須確定它失敗或通過。 必須沒有**人工解釋結果**。 手動驗證測試結果是一個耗時的過程，也可能帶來更多風險。 確保您不會做任何愚蠢的事情，例如設計測試以要求在運行前需要手動安排步驟。 您必須自動執行測試所需的任何設置 – 甚至不依賴于數據庫和預煮數據的存在。 創建一個內存數據庫，創建架構并放入虛擬數據，然后測試代碼。 這樣，您可以運行該測試 N 次，而不必擔心會影響測試執行及其結果的任何外部因素。 #### 及時 實際上，您可以隨時編寫單元測試。 您可以等待代碼準備好投入生產，或者最好集中精力及時編寫單元測試。 作為建議，您應該對單元測試有指導原則或嚴格的規則。 您可以使用審查過程甚至自動化工具來拒絕代碼，而無需進行充分的測試。 您進行的單元測試越多，發現在進行相應的單元測試之前編寫較小的代碼塊所付出的代價就越大。 首先，編寫測試更加容易，其次，當您充實周圍代碼中的其余行為時，測試將立即獲得回報。 ## 額外提示 如果使用 Eclipse 或 IntelliJ IDEA，請考慮合并 [Infinitest](https://infinitest.github.io/) 之類的工具。 在對系統進行更改時，Infinitest 會識別并運行（在后臺）任何可能受到影響的測試。 在更大范圍內，您可以使用持續集成（CI）工具，例如 [Jenkins](https://jenkins.io/) 或 [TeamCity](https://www.jetbrains.com/teamcity/)。 CI 工具會監視您的源倉庫，并在識別到更改后啟動構建/測試過程。 在評論部分中，將您與 **FIRST 原則**相關的查詢發送給我。 學習愉快！ > 參考：本文引用并使用了一些示例，例如 *Andy Hunt 的[“使用 JUnit 進行 Java8 中的實用單元測試”](https://pragprog.com/book/utj2/pragmatic-unit-testing-in-java-8-with-junit)中給出的示例； 杰夫·蘭格，戴夫·托馬斯*。