爲何程序員都討厭寫單元測試？有一個詞叫「相愛相殺」！

面對現實吧！沒有人真的喜歡作單元測試。有不少人向我講述他們超級討厭單元測試。儘管有些人擅長於此，但對於咱們大多數人而言，無論有多少抱怨、多少反感，單元測試都是一件必不可少的事情。今天，我將探討爲何咱們不喜歡單元測試的一些緣由，以及如何經過軟件自動化克服這些障礙。

那麼爲何要進行單元測試呢？

大多數開發團隊都會贊成，儘管他們不喜歡它，可是單元測試其實是有價值的。它能夠幫助開發人員真正理解他們正在開發的代碼，併爲連續測試金字塔打下堅實的基礎（以下圖所示），從而使團隊可以加快敏捷開發的速度，同時減小缺陷滑入開發管道後期的風險。

我會更進一步地說，建立單元測試的過程自己就是一項有益的活動，它能夠幫助開發人員經過不一樣的角度查看他們的代碼，實質上是進行額外的代碼審查。

在進行單元測試時，你能夠從外部角度查看該功能的界面，並從諸如「如何使用個人代碼？」之類的問題中受益。（從而簡化了界面並下降了代碼維護成本），或者，若是我收到無效的數據該怎麼辦？（引導咱們寫出更健壯和可重用的代碼）。

如此重要的單元測試爲啥就不受人待見？

一般，開發團隊進行單元測試的數量不多或徹底不進行，通常是因爲如下因素綜合形成的：（1）提供愈來愈多的功能的壓力（和花費的時間），以及（2）複雜性和時間——建立有價值的單元測試的消耗性質。

這能夠歸結爲開發人員列舉的將限制採用單元測試做爲核心開發實踐的一些常見緣由，包括：

• 難以理解、初始化和/或隔離被測單元的依賴性。
• 肯定要驗證的內容並定義適當的斷言很是耗時，而且一般須要聰明的「猜想工做」。
• 涉及不少手動編碼，一般甚至比實現特定功能或加強功能所需的還要多。
• 只是沒有那麼有趣……開發人員不想感受像是測試人員，他們想花時間交付更多功能。

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

可是不幸的是，全部這些工具都有侷限性，而且開發人員仍然發現了許多難點，例如：

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

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

總之，在開始向測試中添加業務邏輯以前，單元測試的建立仍然須要大量的手動、費時且常常使人費解的工做。

何以解憂？咱們「僱傭」了一個助手！

咱們發現Parasoft Jtest的單元測試助手能夠減輕單元測試的「痛苦」，畢竟，雖然說咱們討厭單元測試，可是咱們也知道它能給咱們帶來的價值遠遠超過了它帶來的麻煩。因此長痛不如短痛！

爲了幫助本身繞過這些痛點，咱們開始評估軟件測試自動化工具。如今，可使用Parasoft Jtest的單元測試助手來解決這些問題，只需單擊按鈕來建立功能齊全的單元測試。

使用UTA建立的測試只是「常規」 JUnit，可是它爲你完成了全部繁瑣的工做。UTA設置測試框架，實例化對象，併爲被測試方法所使用的適當對象和方法調用配置模擬。

這些JUnit能夠做爲標準CI工做流的一部分執行，就像執行現有測試同樣。可是，當UTA執行JUnit（包括你現有的測試）時，對測試的監視方式不只能夠提供代碼覆蓋範圍，還能夠提供分析功能。

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

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

咱們使用UTA來緩解單元測試的痛苦，由於做爲一個10多年專門從事軟件開發和項目定製解決方案的碼農團隊，咱們知道單元測試是建立安全、保障、可靠和高質量的軟件的重要步驟。

若是你也有和我同樣的顧慮與煩惱，歡迎留言討論。固然，若是你嘗試過更好的單元測試方法，也但願不吝賜教，分享給我喲。