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

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

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

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

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

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

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

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

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

“

單元測(cè)試?yán)速M(fèi)了太多的時(shí)間

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

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

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

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

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

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

1.必須遵守 AIR 原則

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

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

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

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

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

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

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

第一階段：?jiǎn)卧獪y(cè)試覆蓋率要求至少25%

第二階段：?jiǎn)卧獪y(cè)試覆蓋率要求至少60%

第三階段：?jiǎn)卧獪y(cè)試覆蓋率要求至少80%

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

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

2.右鍵，Coverage as->Junit

3.覆蓋率結(jié)果會(huì)自動(dòng)在Coverage 視圖中展示出來(lái);

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

【說(shuō)明】 綠色----全覆蓋
      紅色----未覆蓋
      黃色----部分覆蓋

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

1.畫(huà)出程序控制流程圖

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

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

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

以下圖代碼為例說(shuō)明路徑覆蓋法的設(shè)計(jì)單元測(cè)試的過(guò)程

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

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

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

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

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

A

B C

B D E F

B D E G E F

得到了所有的基本路徑，剩下的簡(jiǎn)單了，只需要按照路徑設(shè)計(jì)出對(duì)應(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

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

邊界值

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

異常場(chǎng)景

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

正常場(chǎng)景

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

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

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

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

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

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

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

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

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

調(diào)用邏輯簡(jiǎn)化版如圖所示，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;
   }

}
被測(cè)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的邏輯非常簡(jiǎn)單，現(xiàn)在測(cè)試ServiceA，步驟如下：

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

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

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

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

被測(cè)Controller代碼邏輯如下：

測(cè)試類如下

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

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

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

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