在微服務架構下高覆蓋率的單元測試是保障程式碼質量的第一道也是最重要的關口，應該持之以恆。

背景

單元測試為程式碼質量保駕護航，是提高業務質量的最直接手段，實踐證明，非常多的缺陷完全可以通過單元測試來發現，測試金字塔提出者Martin Fowler 強調如果一個高層測試失敗了，不僅僅表明功能程式碼中存在bug，還意味著單元測試的欠缺。因此，無論何時修復失敗的端到端測試，都應該同時新增相應的單元測試。 而越早發現發現Bug，造成的浪費就會越小，單元測試本身就能夠提供了快速反饋的機制。另外，單元測試是一個優秀的開發工程師必備技能之一，優秀的單元測試是業務快速投產的加速器。

單元測試的意義

雖然對於100%的單元測試覆蓋率我們持有保留態度，但在一個微服務架構基礎設施還不完善、開發人員能力參差不齊、DDD（領域驅動設計）能力不足以應對複雜業務的情況下，單元測試是價效比最高的實踐。單元測試可以充當一個設計工具，它有助於開發人員去思考程式碼結構的設計，讓程式碼更加有利於測試，滿足架構的可測性設計要求。

單元測試的意義包括如下內容：

儘早發現缺陷，降低開發投入成本

85%的缺陷是程式碼階段產生的，單元測試階段可以發現絕大部分軟體缺陷。同時軟體產品的缺陷發現的越早往往會大大的降低其開發的投入成本，其缺陷的發現時間與修復缺陷的成本如下圖中紅色曲線。紅色曲線表明隨著軟體開發的進行，漏洞越早發現，其修復的成本越低，並且其修復成本與開發進度的上升趨勢越在後期越接近於指數上升。

放心重構

無論是對單體專案還是單體專案向微服務架構遷移，程式碼都在不斷的在變化和重構，通過單元測試，開發可以放心的修改重構程式碼，減少改程式碼時心理負擔，提高重構的成功率。

改進設計

越是良好設計的程式碼，越容易編寫單元測試，多個小的方法的單測一般比大方法（成百上千行程式碼）的單測程式碼要簡單、要穩定，一個依賴介面的類一般比依賴具體實現的類容易測試，所以在編寫單測的過程中，如果發現單測程式碼非常難寫，一般表明被測試的程式碼包含了太多的依賴或職責，需要反思程式碼的合理性，進而推進程式碼設計的優化，形成正向迴圈。
選擇測試驅動開發（TDD）的模式進行專案開發，以單元測試引導專案實現。這種模式下單元測試先行，根據單元測試程式碼開發功能程式碼，進而非常精準的實現業務需求，減少返工和缺陷率，可提高專案質量和效率。

“

單元測試的常見誤解

單元測試浪費了太多的時間

雖然不進行單元測試可以更快的交付到後續測試階段，但是在後續整合測試階段、系統測試階段會發現更多的缺陷甚至軟體無法執行的致命缺陷，這些缺陷修復的時間遠超過單元測試的時間。另外沒有單元測試的程式碼後期軟體進行重構或者改進時花費的時間也比有單元測試的所花費的時間要多很多。所以說完整計劃下的單元測試是對時間的更高效的利用。
已經有介面整合測試、系統功能測試進行質量保證了，整合測試階段對介面進行全面測試就可以達到單元測試的要求，沒必要做重複工作在進行單元測試。

介面測試和功能測試無法覆蓋所有的程式碼，這樣如果缺陷存在則將被遺漏，並且Bug將被帶到生產上去。一旦使用者使用過程中觸發了這些沒有測試的程式碼就會帶來嚴重的經濟後果。
跑通一個業務主流程等價於做過單元測試

目前有很多開發人員認為，開發完程式碼之後，寫個main方法，從入口調完所有的模組，最後驗證下返回結果，就認為做過單元測試了，這種想法是及其錯誤的，這充其量算一種不全面的冒煙測試，是對單元測試概念的錯誤認知。

微服務架構下如何開展單元測試

下面將從單元測試所處的階段、單元測試用例設計規範、單元測試實現幾個維度分別介紹如何在微服務架構下開展單元測試。 首先看下單元測試所處的階段，下圖為非TDD模式下單元測試所處的階段

由圖可見單元測試處在特性分支開發完成之後，具體的描述如下：

1.開發人員從Master分支拉取特性分支作為開發分支；
2.開發完特性分支後、程式碼構建、單元測試、靜態程式碼掃描；
3.通過後合併到Master分支，用於投產。
下面看下什麼樣的單元測試用例是優秀的用例，是即滿足執行速度又滿足高覆蓋率的用例。隨行付定製了單元測試規範，下面節選了強制要求的部分規範。優秀的單元測試用例要符合以下用例設計規範的要求。

1.必須遵守 AIR 原則

【說明】單元測試在線上執行時，感覺像空氣（AIR）一樣並不存在，但在測試質量的保障上，卻是非常關鍵的。好的單元測試巨集觀上來說，具有自動化、獨立性、可重複執行的特點。 A：Automatic（自動化） I：Independent（獨立性） R：Repeatable（可重複）
2.單元測試應該是全自動執行的，並且非互動式的

【說明】測試框架通常是定期執行的，執行過程必須完全自動化才有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。單元測試中不準使用 System.out 來進行人肉驗證，必須使用 assert 來驗證。
3.保持單元測試的獨立性

【說明】為了保證單元測試穩定可靠且便於維護，單元測試用例之間決不能互相呼叫，也不能依賴執行的先後次序。反例：method2 需要依賴 method1 的執行，將執行結果做為 method2 的輸入
4.單元測試是可以重複執行的，不能受到外界環境的影響

【說明】單元測試通常會被放到持續整合中，每次有程式碼 check in時單元測試都會被執行。如果單測對外部環境（網路、服務、中介軟體等）有依賴，容易導致持續整合機制的不可用。
5.對於單元測試，要保證測試粒度足夠小，有助於精確定位問題。單測粒度至多是類級別，一般是方法級別

【說明】只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的互動邏輯，那是整合測試的領域
6.核心業務、核心應用、核心模組的增量程式碼確保單元測試通過

【說明】新增程式碼及時補充單元測試，如果新增程式碼影響了原有單元測試，請及時修正
7.單元測試程式碼必須寫在如下工程目錄：src/test/java，不允許寫在業務程式碼目錄下

【說明】原始碼構建時會跳過此目錄，而單元測試框架預設是掃描此目錄
隨行付在推行單元測試落地過程中採用循序漸進的方式，逐步增加單元測試用例達到單元測試規範中規定的覆蓋率要求。需要說明的是我們不是追求覆蓋率這個數字指標，那樣就捨本求末了，我們是通過覆蓋率這個可以量化的指標實現提高程式碼質量的這個根本目的。

第一階段：單元測試覆蓋率要求至少25%

第二階段：單元測試覆蓋率要求至少60%

第三階段：單元測試覆蓋率要求至少80%

隨行付單元測試覆蓋率統計同樣採用SonarQube平臺結合Jenkins工具，Jacoco單元測試覆蓋率工具完成，這個同上篇介紹的靜態程式碼掃描流程是一脈相承的。同時要求開發人員本地的IDE工具中安裝Jacoco覆蓋率外掛，當本地開發完單元測試用例並構建後，即可看到覆蓋率資訊，進而可以快速補充用例，達到覆蓋率要求。 以Eclipse為例，當開發完單元測試程式碼後，按照如下操作即可檢視覆蓋率資訊。

1.選擇需要統計的java測試程式碼或者包;

2.右鍵，Coverage as->Junit

3.覆蓋率結果會自動在Coverage 檢視中展示出來;

4.在Java編輯器中用不同的顏色標識程式碼的覆蓋情況。

【說明】 綠色----全覆蓋
      紅色----未覆蓋
      黃色----部分覆蓋

下面介紹下在微服務下應該如何進行單元測試。為了有效的進行單元測試，需要遵循一定的方法，通常採用路徑覆蓋法設計單元測試用例。所謂路徑覆蓋法就是選取足夠多的測試資料，使程式的每條可能路徑都至少執行一次（如果程式圖中有環，則要求每個環至少經過一次）。具體設計過程參見如下步驟：

1.畫出程式控制流程圖

2.計算圈複雜度

3.找出所有程式基本路徑

4.根據路徑設計測試資料

以下圖程式碼為例說明路徑覆蓋法的設計單元測試的過程

1.首先根據程式碼畫出其對應的流程圖如下，圖中數字代表行號。當條件語句中包含多個條件時應予以拆分，如第13行，拆分為13.1和13.2；對於沒有分支和迴圈的語句可忽略，如第16行。

有了流程圖後，我們可以根據它計算出圈複雜度，這個可以作為測試用例數的上限，圈複雜度計算公式如下：

V（G）= E - N + 2，E是流圖中邊的數量，N是流圖中結點的數量。 V（G）= P + 1 ，P是流圖G中判定結點的數量。

兩個公式用哪個都行，最後的結果應該是一樣的。這裡我們用第二個公式，V（G）= 3 + 1 = 4，也就是我們只需要設計4條用例即可覆蓋所有路徑

接下來就是找出所有基本路徑，基本路徑是從程式的開始結點到結束可以選擇任何的路徑遍歷，但是每條路徑至少應該包含一條已定義路徑不曾用到的邊，所有的基本路徑如下

A

B C

B D E F

B D E G E F

得到了所有的基本路徑，剩下的簡單了，只需要按照路徑設計出對應的入引數據即可

案例1：a = 0, b = 1, 期望值 -1

案例2：a = 1, b = 0, 期望值 -1

案例3: a = 4, b = 2, 期望值 2

案例4：a = 8, b = 12, 期望值 4

除此之外，單元測試用例設計還需要考慮以下場景

邊界值
業務邊界
溢位邊界
字串、陣列、集合等的邊界
異常場景
業務異常
輸入異常（如引數不合法）
正常場景
單個模組的用例設計都可以按照路徑覆蓋法達到語句覆蓋和分支覆蓋，但是對於有依賴關係的模組
在微服務架構下，每個模組之間會存在依賴的情況，為了保持單元測試的獨立性原則，在不依賴於外部條件的情況下製造各種輸入資料，需要藉助Mock技術，其本質是用一個模擬的物件代替真實的物件（例如一個類、模組、函式或者微服務）。模擬物件的行為特徵和真實物件非常相似，採用相同的呼叫邏輯，返回內容按照之前預定義的內容返回，提供返回資料。Mock技術的原理可以用如下案例進行解釋。

當要進行單元測試時，需要給A注入B和C,但是C又依賴D，D又依賴E。這就導致了，A的單元測試不滿足獨立性原則。 但使用了Mock來進行模擬物件後，就可以把這種依賴解耦，只關心A本身的測試，它所依賴的B和C，全部使用Mock出來的物件，並且給MockB和MockC指定一個明確的行為。

在單元測試工具的選擇方面，隨行付單元測試藉助Junit工具和Mockito工具進行單元測試，微服務架構下不管是spring boot還是spring cloud，通常使用@SpringBootTest註解進行單元測試。一個單元測試的實現步驟主要包括4步：

1.設定測試資料

2.Mock依賴的系統並給定預期值，如果沒有依賴這步可以省略

3.在測試中呼叫方法

4.斷言返回的結果是否符合預期

下面以一個非常簡單的例子介紹在微服務架構下如何對spring boot中的controller層和service層進行單元測試。

呼叫邏輯簡化版如圖所示，Controller呼叫ServiceA，ServiceA依賴ServiceB。

被依賴ServiceB的程式碼如下

package cn.vbill.quality.service;
import org.springframework…Service;

@Service
public class ServiceB {
public boolean serve(int param) {
return param % 2 == 0;
}
}
被測ServiceA的程式碼如下

package cn.vbill.quality.service;
import org.springframework.beans…Autowired;
import org.springframework.stereotype.Service;

@Service
public class ServiceA {
@Autowired
private ServiceB srvB;

public String doSomething(int param) {
if (srvB.serve(param)) {
return “even”;
}
return “obb”;
}
}
ServiceA和ServiceB的邏輯非常簡單，現在測試ServiceA，步驟如下：

首先：在gradle中增加測試需要的依賴包

// 可根據實際情況新增版本號
testCompile(“org.springframework.boot:spring-boot-starter-test”)
其次：在src/test/java下面建立測試類，採用@SpringBootTest註解和Mockito技術對ServiceB進行測試和Mock,更多Mockito的使用可以參考其他文章，這裡不過多介紹。程式碼如下：

最後，使用覆蓋率工具檢視單元測試覆蓋率，如下圖所示，實現了100%覆蓋。

ServiceB沒有任何依賴，因此對它測試就按照常規的Junit測試即可，這裡不過多介紹。下面介紹Controller層的單元測試，整體上看 Controller 層的測試和 Service 層大致相同，只不過是我們不去直接呼叫 Controller 的方法，而是通過MockMvc模擬HTTP請求。從邏輯圖上看Controller是直接呼叫ServiceA，因此需要使用Mockito模擬ServiceA。

被測Controller程式碼邏輯如下：

測試類如下

最後，通過覆蓋率工具檢視單元測試覆蓋率為100%，做到了全覆蓋。

以上是如何在微服務架構下進行單元測試進行了詳細的介紹，在微服務架構下高覆蓋率的單元測試是保障程式碼質量的第一道也是最重要的關口，應該持之以恆。

總結

本篇分別從微服務架構下開展單元測試的意義、對單元測試的常見誤解以及如何開展單元測試三個方面進行介紹，單元測試是一項成本低、收益高的實踐，要利用好這把利劍，打好程式碼質量基礎，為後續的質量保證過程添磚加瓦。

作者介紹

王田，隨行付架構部測試架構師。負責測試方法論佈道、自動化測試工具研究與推廣。