摘要：背景最近我們前端團隊在重構(gòu)大量的組件，為了保證代碼質(zhì)量，我要求團隊中的成員必須編寫單元測試，并且測試覆蓋率達到以上?？偨Y(jié)對一個持續(xù)集成的項目來說，單元測試非常重要，同時最好具有較高的測試覆蓋率。

最近我們前端團隊在重構(gòu)大量的 UI 組件，為了保證代碼質(zhì)量，我要求團隊中的成員必須編寫單元測試，并且測試覆蓋率達到 80% 以上。那么問題來了，為什么是 80% 的覆蓋率？ 這是一個硬性的考核指標嗎？

這里所說的測試覆蓋率，是指的是開發(fā)人員寫的單元測試的覆蓋率，不是測試人員的功能測試的覆蓋率。

為什么需要寫單元測試就不再闡述，我相信大家都知道，特別是在持續(xù)集成過程中的重要性。但是，從我的經(jīng)歷來看，當前的軟件市場環(huán)境中，不管是用的瀑布模式，還是螺旋模式，還是敏捷模式，很多軟件沒有寫單元測試。

我也是一個程序員，每天需要寫一些的業(yè)務(wù)代碼，對于寫單元測試來說，確實需要我很多時間和精力，因為它也需要設(shè)計用例和一些體力活。所以在我們的一些項目中也存在很多功能沒有單元測試，主要原因有以下幾個點:

業(yè)務(wù)邏輯更新太快，單元測試不可復用；

業(yè)務(wù)時間緊急，迭代周期時間短，沒有時間寫單元測試；

UI 上很多測試，通過單元測試代碼無法覆蓋。

在《軟件測試》一書中講測試的原則，第一條就是：“完全測試程序是不可能的”。所以對于以上部分需不需測試，取決于你軟件性質(zhì)，時間和團隊。但是對于滿足以下幾點代碼我建議需要編寫單元測試：

和安全相關(guān)的代碼邏輯；

核心的功能模塊，函數(shù)；

短期不會發(fā)生變化的 UI 組件；

提供外部調(diào)用的接口。

如果完全通過測試覆蓋作為質(zhì)量標準是存在問題的，我們在檢查一個測試覆蓋了的時候往往會通過一些工具去檢查，程序員是可以通過一些方式讓數(shù)字看上去漂亮，但是這沒有意義。我們應該把它作為一種發(fā)現(xiàn)未被測試覆蓋的代碼的手段，同時也是一種學習的手段，為什么這段代碼沒有覆蓋到？ 如果這個函數(shù)的參數(shù)發(fā)生了變化會怎么樣？ 這段代碼邏輯怎么這么復雜？

通過分析未被測試覆蓋的代碼，找到是設(shè)計問題，還功能理解有問題，還是說著就是一段廢代碼，它可以幫助開發(fā)者能夠更好的理解背后的事情，可以檢查程序中的廢代碼，然后在以后的設(shè)計中做很好的抽象，做可測試的代碼。

各種開發(fā)語言都有對應的測試框架，可以生成測試報告，在本文中我以前端的 javascript 為示例， karma + istanbul 工具生成報告。

karma 是一個測試框架；

istanbul 是 JavaScript 程序的代碼覆蓋率工具。

怎么生成測試報告這里就不講，有很多教程，也可以查看官方文檔 istanbul。這里我們先來看一下生成出來的測試報告。 以下是 rsuite src/utils 目錄下文件的測試報告, 這是打開的一個生成 html 格式的測試報告：

{% asset_img 1.png RSUITE 測試覆蓋率 %}

從圖中我們可以看到它有四個指標：

Statements: 語句覆蓋率，執(zhí)行到每個語句；

Branches: 分支覆蓋率，執(zhí)行到每個if代碼塊；

Functions: 函數(shù)覆蓋率，調(diào)用到程式中的每一個函數(shù)；

Lines: 行覆蓋率, 執(zhí)行到程序中的每一行。

每一個指標都列出了覆蓋的比例和數(shù)量情況，其中 Statements 與 Lines 比例和數(shù)量是一致的，那它們有什么不同呢？
在代碼中往往存在一些書寫不規(guī)范的情況，比如一行多個語句，這個時候它們統(tǒng)計的覆蓋率就會有差異。 這里又有一個值得思考的問題就是，代碼覆蓋率工具是怎么統(tǒng)計一行多個語句這種代碼的？ 后面講到統(tǒng)計原理的時候會講到。

另外，我們通過圖中可以看出 decorate.js 這個文件相對來說測試覆蓋率較低，我們進入再具體分析一下，在那些地方?jīng)]有覆蓋到：

{% asset_img 2.png decorate.js 測試覆蓋率 %}

從圖中我們可以看到紅色部分和黃色, 都是在測試用例中沒有覆蓋到的地方:

getProps 函數(shù)，該函數(shù)式 export 出去的一個函數(shù)，但是在測試用例中沒有覆蓋到；

typeof size === "object" 代碼塊沒有覆蓋到；

Component.propTypes={}.. 這里黃色部分，是一個默認值設(shè)置，說明這個默認值一直沒有被使用過；

在圖中左側(cè)，顯示行號的地方有一個 12x、9x、4x，這個代表了該行語句被執(zhí)行的次數(shù)， 通過這個清晰的報告，我們可以在代碼中看出那些函數(shù)，那些代碼塊沒有被執(zhí)行，從而去分析原因，修正測試用例，完善代碼邏輯，提高質(zhì)量。

我先來看一下 istanbul 生成的測試報告中有個 lcov.info 文件, 這里我只貼出關(guān)于 decorate.js 文件這部分的內(nèi)容:

SF:/Users/simonguo/workspace/rsuite/src/utils/decorate.js
FN:25,getClassNames
FN:39,getProps
FN:41,(anonymous_2)
FN:50,decorate
FN:51,(anonymous_4)
FNF:5
FNH:3
FNDA:237,getClassNames
FNDA:0,getProps
FNDA:0,(anonymous_2)
FNDA:12,decorate
FNDA:12,(anonymous_4)
DA:4,1
DA:11,1
DA:18,1
DA:27,237
DA:28,237
DA:30,237
DA:32,237
DA:40,0
DA:41,0
DA:42,0
DA:44,0
DA:51,12
DA:52,12
DA:53,12
DA:54,12
DA:56,12
...

FN 代表函數(shù)，
25,39,41,50,51 這些行分布對應源代碼中的函數(shù)開始的行號，
FNF:5 代表一共有5個函數(shù)
FNH:3 其實 3 個函數(shù)被測試所覆蓋，
FNDA:237,getClassNames 代表了 getClassNames 這個函數(shù)被執(zhí)行了 237 次。
...

等等，在文件中詳細記載了行號，以及代碼的執(zhí)行情況，大家可以再對照前面的那張“測試覆蓋率”圖片進行分析，可以詳細的看出整個 lcov.info 文件中記錄內(nèi)容。有了這樣一份記錄信息就能夠生成出一份可視化的測試報告，也可以上傳到 coveralls，展示給大家。 那么這里需要思考的問題是，這樣一份數(shù)據(jù)統(tǒng)計記錄是怎么統(tǒng)計出來的呢？

如果希望有些代碼被忽略，不進入覆蓋統(tǒng)計，istanbul 提供注釋語法 ，查看Ignoring code for coverage purposes

javascript 覆蓋率統(tǒng)計的核心思想，是在源代碼相應的位置注入設(shè)定的統(tǒng)計代碼，當執(zhí)行測試代碼的時候，代碼運行到注入的地方，就會執(zhí)行對應的統(tǒng)計代碼，生成覆蓋率統(tǒng)計報告。大概步驟如下：

第一步：生成語法樹，對源代碼進行語法分析，解析，然后生成語法樹。

生成出來的結(jié)構(gòu)如下，這段代碼來自 esprima， A simple example on Node.js REPL:

> var esprima = require("esprima");
> var program = "const answer = 42";

> esprima.tokenize(program);
[ { type: "Keyword", value: "const" },
  { type: "Identifier", value: "answer" },
  { type: "Punctuator", value: "=" },
  { type: "Numeric", value: "42" } ]

> esprima.parse(program);
{ type: "Program",
  body:
   [ { type: "VariableDeclaration",
       declarations: [Object],
       kind: "const" } ],
  sourceType: "script" }

第二步：注入統(tǒng)計代碼，在語法樹相應的位置注入統(tǒng)計代碼，在程序執(zhí)行到這個位置的時候?qū)ο鄳娜肿兞抠x值，確保執(zhí)行之后能夠根據(jù)全局變量知道代碼的執(zhí)行流程。到這里就解決了前面說的“一行如果有多個語句怎么統(tǒng)計？”的問題。

第三步：再把注入統(tǒng)計代碼的語法樹，生成對應的 javascript 代碼。

以下是 escodegen 的一段示例代碼

// A simple example: the program

escodegen.generate({
    type: "BinaryExpression",
    operator: "+",
    left: { type: "Literal", value: 40 },
    right: { type: "Literal", value: 2 }
});

// produces the string "40 + 2".

第四步：將生成好的 javascript 代碼交給執(zhí)行環(huán)境（nodejs或者瀏覽器）運行。

第五步：執(zhí)行單元測試，產(chǎn)生的統(tǒng)計信息，放到全局標量中。

第六步：根據(jù)全局標量中的覆蓋率信息生成特定格式的報告，這樣我們就看到了 lcov.info 文件和 .html 文件。

這個步驟是依據(jù) istanbul 統(tǒng)計 javasript 的原理，其他語言的一些統(tǒng)計工具沒有接觸過，但是基本的思想應該都是大同小異的。在 javasript 對語法分析，生產(chǎn)語法樹再還原 javasript 代碼是有一些開源工具的，所以如果有興趣的童鞋要自己實現(xiàn)一套代碼覆蓋率的功能，只需要寫好注入的統(tǒng)計代碼邏輯和運行環(huán)境的處理。

對一個持續(xù)集成的項目來說，單元測試非常重要，同時最好具有較高的測試覆蓋率。再次強調(diào)測試覆蓋率是一種發(fā)現(xiàn)未被測試覆蓋的代碼的手段，它不是一個考核質(zhì)量的目標。

另外，我們維護的開源項目 rsuite ,是一套 React 的 UI 組件庫，如果你對此感興趣，或者使用中遇到任何問題，可以聯(lián)系我們 Discord: join chat

本文作者：郭小銘