我們創建了Parasoft Jtest單元測試助手來減輕單元測試的痛苦，因為我們聽說您討厭單元測試，但是我們知道您需要它來成功。

面對現實吧。沒有人真的喜歡做單元測試。有很多人向我講述他們討厭它的故事。盡管有些人擅長于此，但對于我們大多數人而言，盡管有最好、最聰明的抱怨，但這只是必須做的必不可少的事情。今天，我將探討為什么我們不喜歡它的一些原因，以及如何通過軟件自動化克服這些障礙。

那么為什么要進行單元測試呢？

大多數開發團隊都會同意，盡管他們不喜歡它，但是單元測試實際上是有價值的。它可以幫助開發人員真正理解他們正在開發的代碼，并為連續測試金字塔打下堅實的基礎，如右圖所示，從而使團隊能夠加快敏捷開發的速度，同時減少缺陷滑入開發管道后期的風險。

我會更進一步地說，創建單元測試的過程本身就是一項有益的活動，它可以幫助開發人員通過不同的角度查看他們的代碼，實質上是進行額外的代碼審查。

在進行單元測試時，您可以從外部角度查看該功能的界面，并從諸如“如何使用我的代碼？”之類的問題中受益。（從而簡化了界面并降低了代碼維護成本），或者，如果我收到無效的數據該怎么辦？（導致更健壯和可重用的代碼）。

優秀的單元測試的意圖在哪里分解

通常，開發團隊進行單元測試的數量很少或完全不進行，這通常是由于以下因素的組合：（1）提供越來越多的功能的壓力（和花費的時間），以及（2）復雜性和時間——創建有價值的單元測試的消耗性質。

這可以歸結為開發人員列舉的將限制采用單元測試作為核心開發實踐的一些常見原因，包括：

• 難以理解，初始化和/或隔離被測單元的依賴性。
• 確定要驗證的內容并定義適當的斷言非常耗時，并且通常需要聰明的“猜測工作”。
• 涉及很多手動編碼，通常甚至比實現特定功能或增強功能所需的還要多。
• 只是沒有那么有趣……開發人員不想感覺像測試人員，他們想花時間交付更多功能。

為了解決這些限制，目前有幾種現有的工具可以幫助進行單元測試。單元測試和斷言框架提供了標準化的執行格式（即Junit），以無縫集成到CI基礎架構中（例如Jenkins，Bamboo，TeamCity）。IDE有助于創建測試代碼（例如Eclipse，IntelliJ）。模擬框架將代碼與其依賴項隔離開（例如Mockito，PowerMock）。代碼覆蓋工具可讓您對執行的代碼有一些了解（例如Emma，Cobertura，Clover）。調試器允許開發人員監視和檢查單個測試的分步執行。

但是不幸的是，所有這些工具都有局限性，并且開發人員仍然發現許多難點，例如：

• IDE幫助創建單元測試的框架，但沒有“內容”。開發人員仍然需要添加大量代碼來創建執行測試：

• 需要手動定義斷言，并且必須執行測試以查看是否已斷言正確的值。
• 模擬框架需要大量的手動代碼來實例化和配置，以及有關如何正確使用它們的知識。
• 覆蓋率工具可以洞悉已執行的測試涵蓋了哪些代碼，但不能洞悉測試的運行時行為。
• 調試器可用于單個測試，但不能擴展為監視整個測試運行的方式。

總之，在開始向測試中添加業務邏輯之前，單元測試的創建仍然需要大量的手動，費時且經常令人費解的工作。 

解決方案？我們創建了一個助手！

為了構建可幫助您繞過這些痛點的工具，我們轉向了軟件測試自動化（當然）。現在，可以使用Parasoft Jtest的單元測試助手來幫助您單擊按鈕來創建功能齊全的單元測試。

使用UTA創建的測試只是“常規” JUnit，但是為您完成了所有繁瑣的工作。UTA設置測試框架，實例化對象，并為被測試方法所使用的適當對象和方法調用配置模擬。

這些JUnit可以作為標準CI工作流的一部分執行，就像執行現有測試一樣。但是，當UTA執行JUnit（包括您現有的測試）時，對測試的監視方式不僅可以提供代碼覆蓋范圍，還可以提供分析功能。

通過在運行時分析測試，UTA可以提供一系列建議，其中許多具有快速修復的功能，可幫助您一鍵式執行操作，例如：

• 突出顯示已更改并應聲明的對象值，
• 確定應該模擬的方法調用，以更好地隔離被測代碼，以及
• 查找無法自動“清理”的測試并創建潛在的不穩定測試環境（例如，由于使用了線程、外部文件、靜態字段或系統屬性）。

我們創建UTA來緩解單元測試的痛苦，因為作為一家專門從事軟件完善的組織，我們知道單元測試是創建安全、可靠、保障和高質量的軟件的重要步驟。因此，我希望在以后的會議和活動中與您進行對話，在這里您可以告訴我有關使用UTA帶回愛的經驗，而不必告訴我您討厭單元測試的程度。

要獲得Jtest UTA的免費演示，請。

資源

要查看運行中的單元測試助手，請查看以下視頻：