摘要：輸出結(jié)果需要人工檢查的測試不是一個好的單元測試。為了有效的進(jìn)行單元測試，需要遵循一定的方法，通常采用路徑覆蓋法設(shè)計單元測試用例。

在微服務(wù)架構(gòu)下高覆蓋率的單元測試是保障代碼質(zhì)量的第一道也是最重要的關(guān)口，應(yīng)該持之以恒。

單元測試為代碼質(zhì)量保駕護(hù)航，是提高業(yè)務(wù)質(zhì)量的最直接手段，實踐證明，非常多的缺陷完全可以通過單元測試來發(fā)現(xiàn)，測試金字塔提出者M(jìn)artin Fowler 強(qiáng)調(diào)如果一個高層測試失敗了，不僅僅表明功能代碼中存在bug，還意味著單元測試的欠缺。因此，無論何時修復(fù)失敗的端到端測試，都應(yīng)該同時添加相應(yīng)的單元測試。 而越早發(fā)現(xiàn)發(fā)現(xiàn)Bug，造成的浪費就會越小，單元測試本身就能夠提供了快速反饋的機(jī)制。另外，單元測試是一個優(yōu)秀的開發(fā)工程師必備技能之一，優(yōu)秀的單元測試是業(yè)務(wù)快速投產(chǎn)的加速器。

雖然對于100%的單元測試覆蓋率我們持有保留態(tài)度，但在一個微服務(wù)架構(gòu)基礎(chǔ)設(shè)施還不完善、開發(fā)人員能力參差不齊、DDD（領(lǐng)域驅(qū)動設(shè)計）能力不足以應(yīng)對復(fù)雜業(yè)務(wù)的情況下，單元測試是性價比最高的實踐。單元測試可以充當(dāng)一個設(shè)計工具，它有助于開發(fā)人員去思考代碼結(jié)構(gòu)的設(shè)計，讓代碼更加有利于測試，滿足架構(gòu)的可測性設(shè)計要求。

單元測試的意義包括如下內(nèi)容：

盡早發(fā)現(xiàn)缺陷，降低開發(fā)投入成本

85%的缺陷是代碼階段產(chǎn)生的，單元測試階段可以發(fā)現(xiàn)絕大部分軟件缺陷。同時軟件產(chǎn)品的缺陷發(fā)現(xiàn)的越早往往會大大的降低其開發(fā)的投入成本，其缺陷的發(fā)現(xiàn)時間與修復(fù)缺陷的成本如下圖中紅色曲線。紅色曲線表明隨著軟件開發(fā)的進(jìn)行，漏洞越早發(fā)現(xiàn)，其修復(fù)的成本越低，并且其修復(fù)成本與開發(fā)進(jìn)度的上升趨勢越在后期越接近于指數(shù)上升。

無論是對單體項目還是單體項目向微服務(wù)架構(gòu)遷移，代碼都在不斷的在變化和重構(gòu)，通過單元測試，開發(fā)可以放心的修改重構(gòu)代碼，減少改代碼時心理負(fù)擔(dān)，提高重構(gòu)的成功率。

越是良好設(shè)計的代碼，越容易編寫單元測試，多個小的方法的單測一般比大方法（成百上千行代碼）的單測代碼要簡單、要穩(wěn)定，一個依賴接口的類一般比依賴具體實現(xiàn)的類容易測試，所以在編寫單測的過程中，如果發(fā)現(xiàn)單測代碼非常難寫，一般表明被測試的代碼包含了太多的依賴或職責(zé)，需要反思代碼的合理性，進(jìn)而推進(jìn)代碼設(shè)計的優(yōu)化，形成正向循環(huán)。
選擇測試驅(qū)動開發(fā)（TDD）的模式進(jìn)行項目開發(fā)，以單元測試引導(dǎo)項目實現(xiàn)。這種模式下單元測試先行，根據(jù)單元測試代碼開發(fā)功能代碼，進(jìn)而非常精準(zhǔn)的實現(xiàn)業(yè)務(wù)需求，減少返工和缺陷率，可提高項目質(zhì)量和效率。

“

單元測試?yán)速M了太多的時間

雖然不進(jìn)行單元測試可以更快的交付到后續(xù)測試階段，但是在后續(xù)集成測試階段、系統(tǒng)測試階段會發(fā)現(xiàn)更多的缺陷甚至軟件無法運行的致命缺陷，這些缺陷修復(fù)的時間遠(yuǎn)超過單元測試的時間。另外沒有單元測試的代碼后期軟件進(jìn)行重構(gòu)或者改進(jìn)時花費的時間也比有單元測試的所花費的時間要多很多。所以說完整計劃下的單元測試是對時間的更高效的利用。
已經(jīng)有接口集成測試、系統(tǒng)功能測試進(jìn)行質(zhì)量保證了，集成測試階段對接口進(jìn)行全面測試就可以達(dá)到單元測試的要求，沒必要做重復(fù)工作在進(jìn)行單元測試。

接口測試和功能測試無法覆蓋所有的代碼，這樣如果缺陷存在則將被遺漏，并且Bug將被帶到生產(chǎn)上去。一旦用戶使用過程中觸發(fā)了這些沒有測試的代碼就會帶來嚴(yán)重的經(jīng)濟(jì)后果。
跑通一個業(yè)務(wù)主流程等價于做過單元測試

目前有很多開發(fā)人員認(rèn)為，開發(fā)完代碼之后，寫個main方法，從入口調(diào)完所有的模塊，最后驗證下返回結(jié)果，就認(rèn)為做過單元測試了，這種想法是及其錯誤的，這充其量算一種不全面的冒煙測試，是對單元測試概念的錯誤認(rèn)知。

下面將從單元測試所處的階段、單元測試用例設(shè)計規(guī)范、單元測試實現(xiàn)幾個維度分別介紹如何在微服務(wù)架構(gòu)下開展單元測試。 首先看下單元測試所處的階段，下圖為非TDD模式下單元測試所處的階段

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

1.開發(fā)人員從Master分支拉取特性分支作為開發(fā)分支；
2.開發(fā)完特性分支后、代碼構(gòu)建、單元測試、靜態(tài)代碼掃描；
3.通過后合并到Master分支，用于投產(chǎn)。
下面看下什么樣的單元測試用例是優(yōu)秀的用例，是即滿足運行速度又滿足高覆蓋率的用例。隨行付定制了單元測試規(guī)范，下面節(jié)選了強(qiáng)制要求的部分規(guī)范。優(yōu)秀的單元測試用例要符合以下用例設(shè)計規(guī)范的要求。

1.必須遵守 AIR 原則

【說明】單元測試在線上運行時，感覺像空氣（AIR）一樣并不存在，但在測試質(zhì)量的保障上，卻是非常關(guān)鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重復(fù)執(zhí)行的特點。 A：Automatic（自動化） I：Independent（獨立性） R：Repeatable（可重復(fù)）
2.單元測試應(yīng)該是全自動執(zhí)行的，并且非交互式的

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

【說明】為了保證單元測試穩(wěn)定可靠且便于維護(hù)，單元測試用例之間決不能互相調(diào)用，也不能依賴執(zhí)行的先后次序。反例：method2 需要依賴 method1 的執(zhí)行，將執(zhí)行結(jié)果做為 method2 的輸入
4.單元測試是可以重復(fù)執(zhí)行的，不能受到外界環(huán)境的影響

【說明】單元測試通常會被放到持續(xù)集成中，每次有代碼 check in時單元測試都會被執(zhí)行。如果單測對外部環(huán)境（網(wǎng)絡(luò)、服務(wù)、中間件等）有依賴，容易導(dǎo)致持續(xù)集成機(jī)制的不可用。
5.對于單元測試，要保證測試粒度足夠小，有助于精確定位問題。單測粒度至多是類級別，一般是方法級別

【說明】只有測試粒度小才能在出錯時盡快定位到出錯位置。單測不負(fù)責(zé)檢查跨類或者跨系統(tǒng)的交互邏輯，那是集成測試的領(lǐng)域
6.核心業(yè)務(wù)、核心應(yīng)用、核心模塊的增量代碼確保單元測試通過

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

【說明】源碼構(gòu)建時會跳過此目錄，而單元測試框架默認(rèn)是掃描此目錄
隨行付在推行單元測試落地過程中采用循序漸進(jìn)的方式，逐步增加單元測試用例達(dá)到單元測試規(guī)范中規(guī)定的覆蓋率要求。需要說明的是我們不是追求覆蓋率這個數(shù)字指標(biāo)，那樣就舍本求末了，我們是通過覆蓋率這個可以量化的指標(biāo)實現(xiàn)提高代碼質(zhì)量的這個根本目的。

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

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

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

隨行付單元測試覆蓋率統(tǒng)計同樣采用SonarQube平臺結(jié)合Jenkins工具，Jacoco單元測試覆蓋率工具完成，這個同上篇介紹的靜態(tài)代碼掃描流程是一脈相承的。同時要求開發(fā)人員本地的IDE工具中安裝Jacoco覆蓋率插件，當(dāng)本地開發(fā)完單元測試用例并構(gòu)建后，即可看到覆蓋率信息，進(jìn)而可以快速補(bǔ)充用例，達(dá)到覆蓋率要求。 以Eclipse為例，當(dāng)開發(fā)完單元測試代碼后，按照如下操作即可查看覆蓋率信息。

1.選擇需要統(tǒng)計的java測試代碼或者包;

2.右鍵，Coverage as->Junit

3.覆蓋率結(jié)果會自動在Coverage 視圖中展示出來;

4.在Java編輯器中用不同的顏色標(biāo)識代碼的覆蓋情況。

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

下面介紹下在微服務(wù)下應(yīng)該如何進(jìn)行單元測試。為了有效的進(jìn)行單元測試，需要遵循一定的方法，通常采用路徑覆蓋法設(shè)計單元測試用例。所謂路徑覆蓋法就是選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次（如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次）。具體設(shè)計過程參見如下步驟：

1.畫出程序控制流程圖

2.計算圈復(fù)雜度

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

4.根據(jù)路徑設(shè)計測試數(shù)據(jù)

以下圖代碼為例說明路徑覆蓋法的設(shè)計單元測試的過程

1.首先根據(jù)代碼畫出其對應(yīng)的流程圖如下，圖中數(shù)字代表行號。當(dāng)條件語句中包含多個條件時應(yīng)予以拆分，如第13行，拆分為13.1和13.2；對于沒有分支和循環(huán)的語句可忽略，如第16行。

有了流程圖后，我們可以根據(jù)它計算出圈復(fù)雜度，這個可以作為測試用例數(shù)的上限，圈復(fù)雜度計算公式如下：

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

兩個公式用哪個都行，最后的結(jié)果應(yīng)該是一樣的。這里我們用第二個公式，V（G）= 3 + 1 = 4，也就是我們只需要設(shè)計4條用例即可覆蓋所有路徑

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

A

B C

B D E F

B D E G E F

得到了所有的基本路徑，剩下的簡單了，只需要按照路徑設(shè)計出對應(yīng)的入?yún)?shù)據(jù)即可

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

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

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

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

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

邊界值

 業(yè)務(wù)邊界
 溢出邊界
字符串、數(shù)組、集合等的邊界

異常場景

業(yè)務(wù)異常
輸入異常（如參數(shù)不合法）

正常場景

單個模塊的用例設(shè)計都可以按照路徑覆蓋法達(dá)到語句覆蓋和分支覆蓋，但是對于有依賴關(guān)系的模塊

在微服務(wù)架構(gòu)下，每個模塊之間會存在依賴的情況，為了保持單元測試的獨立性原則，在不依賴于外部條件的情況下制造各種輸入數(shù)據(jù)，需要借助Mock技術(shù)，其本質(zhì)是用一個模擬的對象代替真實的對象（例如一個類、模塊、函數(shù)或者微服務(wù)）。模擬對象的行為特征和真實對象非常相似，采用相同的調(diào)用邏輯，返回內(nèi)容按照之前預(yù)定義的內(nèi)容返回，提供返回數(shù)據(jù)。Mock技術(shù)的原理可以用如下案例進(jìn)行解釋。

當(dāng)要進(jìn)行單元測試時，需要給A注入B和C,但是C又依賴D，D又依賴E。這就導(dǎo)致了，A的單元測試不滿足獨立性原則。 但使用了Mock來進(jìn)行模擬對象后，就可以把這種依賴解耦，只關(guān)心A本身的測試，它所依賴的B和C，全部使用Mock出來的對象，并且給MockB和MockC指定一個明確的行為。

在單元測試工具的選擇方面，隨行付單元測試借助Junit工具和Mockito工具進(jìn)行單元測試，微服務(wù)架構(gòu)下不管是spring boot還是spring cloud，通常使用@SpringBootTest注解進(jìn)行單元測試。一個單元測試的實現(xiàn)步驟主要包括4步：

1.設(shè)置測試數(shù)據(jù)

2.Mock依賴的系統(tǒng)并給定預(yù)期值，如果沒有依賴這步可以省略

3.在測試中調(diào)用方法

4.斷言返回的結(jié)果是否符合預(yù)期

下面以一個非常簡單的例子介紹在微服務(wù)架構(gòu)下如何對spring boot中的controller層和service層進(jìn)行單元測試。

調(diào)用邏輯簡化版如圖所示，Controller調(diào)用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的邏輯非常簡單，現(xiàn)在測試ServiceA，步驟如下：

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

// 可根據(jù)實際情況添加版本號
testCompile("org.springframework.boot:spring-boot-starter-test")
其次：在src/test/java下面創(chuàng)建測試類，采用@SpringBootTest注解和Mockito技術(shù)對ServiceB進(jìn)行測試和Mock,更多Mockito的使用可以參考其他文章，這里不過多介紹。代碼如下：

最后，使用覆蓋率工具查看單元測試覆蓋率，如下圖所示，實現(xiàn)了100%覆蓋。

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

被測Controller代碼邏輯如下：

測試類如下

最后，通過覆蓋率工具查看單元測試覆蓋率為100%，做到了全覆蓋。

以上是如何在微服務(wù)架構(gòu)下進(jìn)行單元測試進(jìn)行了詳細(xì)的介紹，在微服務(wù)架構(gòu)下高覆蓋率的單元測試是保障代碼質(zhì)量的第一道也是最重要的關(guān)口，應(yīng)該持之以恒。

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

王田，隨行付架構(gòu)部測試架構(gòu)師。負(fù)責(zé)測試方法論布道、自動化測試工具研究與推廣。