什么是單元測試？

單元測試是測試應用程序的各個單元或組件的實踐，以驗證每個單元是否正常工作。通常，unit（單元）應該是應用程序的一小部分 - 在Java中，它通常是單個類。請注意，并不是嚴格定義“unit”，開發人員需要決定每個測試的測試代碼范圍。

人們有時將“單元測試”一詞與“集成測試”或“端到端測試”進行對比。不同之處在于，通常，單元測試是用于驗證單個可測試單元的行為，而集成測試則驗證多個組件的行為或整個應用程序的行為。就像我所說，構成“單元”的定義并沒有嚴格定義，由你來決定每個測試的范圍。

為什么選擇單元測試？

單元測試是一種經過驗證的技術，可確保軟件質量，并帶來很多好處。以下是選擇單元測試的一些重要原因：

• 單元測試驗證了您的每個軟件不僅在今天可以正常運行，而且在將來也繼續工作，為未來的發展奠定了堅實的基礎。
• 單元測試在生產過程的早期階段識別了缺陷，這減少了在開發周期的后期階段修復它們的成本。
• 經過單元測試的代碼通常更容易重構，因為可以快速重新運行測試以驗證行為沒有改變。
• 編寫單元測試迫使開發人員考慮生產代碼的設計如何使其適合于單元測試，并使開發人員從不同的角度看待他們的代碼，鼓勵他們在實現中考慮極端情況和錯誤條件。
• 在代碼審查過程中包括單元測試可以揭示修改后的代碼或新代碼應該如何工作。此外，審核人員可以確認測試是否良好。

不幸的是，經常開發人員要么根本不編寫單元測試，要么沒有編寫足夠的測試，要么不維護它們。可以理解，畢竟單元測試有時候寫起來很棘手，或者維護起來很費時。有時會遇到最后期限，感覺編寫測試會讓我們錯過截止日期。但是，沒有編寫足夠的單元測試或沒有編寫好的單元測試容易跳入一個陷入風險的陷阱。

因此，請考慮以下最佳實踐建議，了解如何編寫干凈，可維護，自動化的測試，以最少的時間和精力為您提供單元測試的所有好處。

單元測試最佳實踐

讓我們看一下構建，運行和維護單元測試的一些最佳實踐，以獲得最佳結果。

單元測試應該值得信賴

如果代碼被破壞，并且只有代碼被破壞，測試才會失敗。如果沒有，我們無法相信測試結果告訴我們的是什么。

單元測試應該是可維護和可讀的

當生產代碼發生變化時，通常需要更新測試，并且可能還需要調試。所以它必須易于閱讀和理解測試，不僅適用于編寫它的人，也適用于其他開發人員。始終組織和命名您的測試，以提高清晰度和可讀性。

單元測試應驗證單個用例

好的測試驗證一件事或者只驗證一件事，這意味著他們通常會驗證一個用例。遵循此最佳實踐的測試更簡單，更易理解，這有利于可維護性和調試。驗證多個事物的測試很容易變得復雜且耗時。不要讓這種情況發生。

另一個最佳實踐是使用最少數量的斷言。有些人建議每次測試只有一個斷言（這可能有點過于嚴格限制了）; 我們的想法是專注于僅驗證您正在測試的用例所需的內容。

單元測試應該是隔離的

測試應該可以在任何機器上以任何順序運行，而不會相互影響。如果可能，測試應該不依賴于環境因素或全局/外部狀態。具有這些依賴性的測試更難以運行并且通常不穩定，使得它們更難以調試和修復，并且最終花費的時間比它們節省的時間更多（參見上面的可靠信息）。

幾年前Martin Fowler撰寫了一篇關于代碼的文章，描述了應用程序代碼中的依賴用法，以及如何相應地設計測試。在他的文章中，“孤獨”代碼不依賴于其他單元（它更獨立），而“社交”代碼確實與其他組件交互。如果應用程序代碼是單獨的，那么測試很簡單......但是對于正在測試的社交代碼，您可以構建“單獨”或“社交”測試。“社交測試”將依賴于實際依賴性以驗證行為，而“孤立測試”將測試中的代碼與依賴性隔離開來。您可以使用模擬來隔離測試中的代碼，并為“社交”構建“單獨”測試 碼。我們將在下面看看如何做到這一點。

圖1：社交與孤獨測試。資料來源：Martin Fowler，2014年

一般來說，使用mock（模擬）作為依賴項使我們作為測試人員的生活更容易，因為我們可以為社會化代碼生成“單獨的測試”。對復雜代碼的社交測試可能需要大量設置，并且可能違反被隔離和可重復的原則。但是由于模擬是在測試中創建和配置的，因此它是自包含的，我們可以更好地控制依賴項的行為。另外，我們可以測試更多代碼路徑。例如，我可以返回自定義值或從模擬中拋出異常，以覆蓋邊界或錯誤條件。

單元測試應該是自動化的

確保測試正在自動化過程中運行。這可以是每天，也可以是每小時，也可以是持續集成或交付流程。報告需要可供團隊中的每個人訪問和審核。作為一個團隊，請討論您關注的指標：代碼覆蓋率，修改后的代碼覆蓋率，正在運行的測試數量，性能等。

通過觀察這些數字可以學到很多東西，而這些數字的巨大變化往往表明可以立即解決的回歸問題。

使用良好的單元和集成測試混合

Michael Cohn的書“ 使用敏捷成功：使用Scrum進行軟件開發”，  使用測試金字塔模型解決了這個問題（見下圖中的插圖）。這是描述測試資源理想分布的常用模型。這個想法是，當你進入金字塔時，測試通常構建起來更復雜，更脆弱，運行速度更慢，調試速度更慢。較低級別更加獨立，更集成，更快速，更易于構建和調試。因此，自動化單元測試應該構成您的大部分測試。

單元測試應驗證所有細節，邊角情況和邊界條件等。應更謹慎地使用組件，集成，UI和功能測試，以驗證API或應用程序的整體行為。手動測試應該是整個金字塔結構的最小百分比，但仍然可用于發布驗收和探索性測試。該模型為組織提供了高水平的自動化和測試覆蓋率，因此他們可以擴展測試工作并將與構建，運行和維護測試相關的成本保持在最低水平。

單元測試應在有組織的測試實踐中執行

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

編寫測試以及代碼不僅適用于新行為或計劃更改，它對于錯誤修復也很重要。您修復的每個錯誤都應該有一個測試，以驗證錯誤是否已修復。這可以確保錯誤在將來保持不變。

對失敗的測試采用零容忍策略。如果您的團隊忽略了測試結果，那么為什么要進行測試呢？測試失敗應該表明真正的問題......所以在他們浪費QA的時間之前立即解決這些問題，或者更糟糕的是，他們進入已發布的產品。

解決故障所需的時間越長，這些故障最終會花費您的組織的時間和金錢就越多。因此，在重構期間運行測試，在提交代碼之前運行測試，并且在測試通過之前不要將任務視為“完成”。

最后，保持這些測試。正如我之前所說，如果你在應用程序發生變化時沒有及時更新這些測試，那么它們就會失去價值。特別是如果他們失敗了，那么失敗的測試每次失敗都需要花費時間和金錢來進行調查。當代碼更改時，根據需要重構測試。

正如您所看到的，最大化您在單元測試中投入的金錢和時間的回報需要在應用最佳實踐方面進行一些投資。但最終，最后的獎勵值得初步投資。

代碼覆蓋率如何？

通常，代碼覆蓋率是在自動化測試運行時執行多少生產代碼的度量。通過運行一系列測試并查看代碼覆蓋率數據，您可以大致了解正在測試的應用程序的數量。

代碼覆蓋范圍很多 - 最常見的是線覆蓋和分支覆蓋。大多數工具都專注于線路覆蓋，它只是告訴您是否覆蓋了特定線路。分支更精細，因為它告訴您是否覆蓋了代碼中的每條路徑。

代碼覆蓋率是一個重要的指標，但請記住，增加它是達到目的的手段。它非常適合在測試中找到差距，但這并不是唯一需要關注的問題。注意不要花費太多精力來實現100％的覆蓋率 - 它甚至可能不可行或不可行，而且測試的質量確實是重要的。話雖如此，為您的項目實現至少60％的覆蓋率是一個很好的起點，80％或更多是一個很好的目標。顯然，由您來決定該目標應該是什么。

如果您擁有自動化工具，不僅可以測量代碼覆蓋率，還可以跟蹤測試覆蓋的修改代碼量，這也很有價值，因為這可以提供對是否正在編寫足夠的測試以及生產代碼更改的可見性。

請參閱Parasoft報告和分析中心的示例代碼覆蓋率報告，如果您使用Parasoft Jtest進行單元測試，則可以瀏覽：

另外要記住的是，在編寫新測試時，要注意單獨關注行覆蓋，因為單行代碼可能導致多個代碼路徑，因此請確保測試驗證這些代碼路徑。線路覆蓋是一個有用的快速指示器，但它不是唯一要尋找的東西。

增加覆蓋率的最明顯方法是為更多代碼路徑添加更多測試，以及測試方法的更多用例。增加覆蓋率的有效方法是使用參數化測試。對于Junit4，內置了Junit4參數化功能和第三方庫，如JunitParams。Junit5具有內置參數化功能。

最后，如果您還沒有跟蹤測試覆蓋率，我強烈建議您現在就開始。有很多工具可以提供幫助，比如Parasoft Jtest。首先測量您當前的覆蓋率數字，然后設定應該在哪里的目標，首先解決重要的差距，然后從那里開始工作。

總結

盡管單元測試是一種用于確保軟件質量的成熟技術，但它仍然被認為是開發人員的負擔，許多團隊仍然在努力解決這個問題。為了充分利用測試和自動化測試工具，測試必須值得信賴，可維護，可讀，獨立，并用于驗證單個用例。自動化是使單元測試可行且可擴展的關鍵。

此外，軟件團隊需要練習良好的測試技術，例如編寫和審查測試以及應用程序代碼，維護測試以及確保立即跟蹤和修復失敗的測試。采用這些單元測試最佳實踐可以快速提高單元測試結果。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或資源的朋友，請