單元測試是眾所周知的做法，但還有很大的改進空間！在這篇文章中，我們討論最有效的單元測試最佳實踐，包括在此過程中最大化自動化工具的方法。我們還將討論代碼覆蓋率、模擬依賴關(guān)系和整體測試策略。

什么是單元測試？
單元測試是測試應(yīng)用程序的各個單元或組件的做法，以驗證每個單元是否正常工作。一般來說，一個單元應(yīng)該是應(yīng)用程序的一小部分——在 Java 中，它通常是一個類。請注意，我在這里并沒有嚴格定義“單元”，而是由開發(fā)人員決定每個測試的測試代碼的范圍。

人們有時會將術(shù)語“單元測試”與“集成測試”或“端到端測試”進行對比。區(qū)別在于，通常，單元測試是為了驗證單個可測試單元的行為，而集成測試是驗證多個組件一起或整個應(yīng)用程序的行為。正如我所說，“單元”的構(gòu)成并沒有嚴格定義，每個測試的范圍由您決定。

為什么要進行單元測試？
單元測試是一種經(jīng)過驗證的確保軟件質(zhì)量的技術(shù)，具有很多好處。以下是進行單元測試的幾個重要原因：

單元測試驗證您的每個軟件不僅現(xiàn)在可以正常工作，而且在未來也可以繼續(xù)工作，為未來的開發(fā)提供堅實的基礎(chǔ)。
單元測試可以在生產(chǎn)過程的早期階段識別缺陷，從而降低在開發(fā)周期后期修復這些缺陷的成本。
經(jīng)過單元測試的代碼通常重構(gòu)起來更安全，因為可以快速重新運行測試以驗證行為沒有改變。
編寫單元測試迫使開發(fā)人員考慮生產(chǎn)代碼的設(shè)計如何，以使其適合單元測試，并使開發(fā)人員從不同的角度看待他們的代碼，鼓勵他們在實現(xiàn)中考慮極端情況和錯誤情況。
在代碼審查過程中包括單元測試可以揭示修改后的或新的代碼應(yīng)該如何工作。另外，審閱者可以確認測試是否良好。
不幸的是，很多時候，開發(fā)人員要么根本不編寫單元測試，要么不編寫足夠的測試，要么不維護它們。我理解——單元測試有時編寫起來很棘手，或者維護起來很耗時。有時需要滿足最后期限，感覺編寫測試會讓我們錯過那個最后期限。但是，沒有編寫足夠的單元測試或沒有編寫良好的單元測試是一個很容易陷入的危險陷阱。

因此，請考慮我以下關(guān)于如何編寫干凈、可維護、自動化測試的最佳實踐建議，這些測試可以讓您以最少的時間和精力享受單元測試的所有好處。

單元測試最佳實踐
讓我們看一下構(gòu)建、運行和維護單元測試的一些最佳實踐，以獲得最佳結(jié)果。

單元測試應(yīng)該值得信賴
如果代碼被破壞并且僅當代碼被破壞時測試必定失敗。如果不是，我們就不能相信測試結(jié)果告訴我們的內(nèi)容。

單元測試應(yīng)該是可維護和可讀的
當生產(chǎn)代碼發(fā)生變化時，測試通常需要更新，也可能需要調(diào)試。因此，測試必須易于閱讀和理解，不僅對于編寫測試的人來說，而且對于其他開發(fā)人員來說也是如此。始終為了清??晰和可讀性而組織和命名您的測試。

單元測試應(yīng)該驗證單個用例
好的測試只能驗證一件事，而且只能驗證一件事，這意味著它們通常會驗證單個用例。遵循此最佳實踐的測試更簡單且更易于理解，這有利于可維護性和調(diào)試。驗證不止一件事的測試很容易變得復雜且維護起來耗時。不要讓這種事發(fā)生。

另一個最佳實踐是使用最少數(shù)量的斷言。有些人建議每個測試只使用一個斷言（這可能有點過于嚴格）；這個想法是專注于僅驗證您正在測試的用例所需的內(nèi)容。

單元測試應(yīng)該隔離
測試應(yīng)該可以在任何機器上以任何順序運行，而不會相互影響。如果可能，測試不應(yīng)依賴于環(huán)境因素或全局/外部狀態(tài)。具有這些依賴項的測試更難運行并且通常不穩(wěn)定，這使得它們更難調(diào)試和修復，并且最終花費的時間比節(jié)省的時間更多（請參閱上面的trustworthy）。

幾年前，Martin Fowler撰寫了有關(guān) “孤獨”與“社交”代碼的文章，以描述應(yīng)用程序代碼中的依賴項使用情況，以及如何相應(yīng)地設(shè)計測試。在他的文章中，“獨立”代碼不依賴于其他單元（它更加獨立），而“社交”代碼確實與其他組件交互。如果應(yīng)用程序代碼是孤獨的，那么測試很簡單，但對于被測試的社交代碼，您可以構(gòu)建“孤獨”或“社交”測試?！吧缃粶y試”將依賴于真實的依賴關(guān)系來驗證行為，而“單獨測試”則將被測代碼與依賴關(guān)系隔離開來。您可以使用模擬來隔離被測代碼，并為“社交”代碼構(gòu)建“單獨”測試。我們將在下面看看如何做到這一點。

一般來說，使用模擬來處理依賴關(guān)系使我們作為測試人員的生活更輕松，因為我們可以為社交代碼生成“單獨的測試”。對復雜代碼的社交測試可能需要大量設(shè)置，并且可能違反隔離和可重復的原則。但由于模擬是在測試中創(chuàng)建和配置的，因此它是獨立的，我們可以更好地控制依賴項的行為。另外，我們可以測試更多代碼路徑。例如，我可以返回自定義值或從模擬中拋出異常，以覆蓋邊界或錯誤條件。

單元測試應(yīng)該自動化
確保測試在自動化過程中運行。這可以是每天，也可以是每小時，也可以是在持續(xù)集成或交付過程中。團隊中的每個人都需要能夠訪問和審查這些報告。作為一個團隊，討論您關(guān)心哪些指標：代碼覆蓋率、修改后的代碼覆蓋率、正在運行的測試數(shù)量、性能等。

通過查看這些數(shù)字可以學到很多東西，這些數(shù)字的大幅變化通常表明可以立即解決回歸問題。
單元測試應(yīng)驗證所有細節(jié)、極端情況和邊界條件等。應(yīng)更加謹慎地使用組件、集成、UI 和功能測試，以驗證 API 或應(yīng)用程序作為一個整體的行為。手動測試應(yīng)該占整個金字塔結(jié)構(gòu)的最小百分比，但對于發(fā)布驗收和探索性測試仍然有用。該模型為組織提供了高水平的自動化和測試覆蓋率，以便他們可以擴大測試工作并將與構(gòu)建、運行和維護測試相關(guān)的成本保持在最低水平。

單元測試應(yīng)在有組織的測試實踐中執(zhí)行
為了推動各級測試的成功，并使單元測試過程可擴展且可持續(xù)，您將需要一些額外的實踐。首先，這意味著在編寫應(yīng)用程序代碼時編寫單元測試。一些組織在應(yīng)用程序代碼之前編寫測試（測試驅(qū)動或行為驅(qū)動編程）。重要的是測試與應(yīng)用程序代碼齊頭并進。測試和應(yīng)用程序代碼甚至應(yīng)該在代碼審查過程中一起審查。評論可以幫助您理解正在編寫的代碼（因為它們可以看到預期的行為）并改進測試！