隨行付微服務測試之單元測試

在微服務架構下高覆蓋率的單元測試是保障代碼質量的第一道也是最重要的關口，應該鍥而不捨。

背景

單元測試爲代碼質量保駕護航，是提升業務質量的最直接手段，實踐證實，很是多的缺陷徹底能夠經過單元測試來發現，測試金字塔提出者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%，作到了全覆蓋。

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

總結

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

做者介紹

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