前言

在我們開(kāi)發(fā)完一個(gè)組件庫(kù)的后，在做單元測(cè)試時(shí)，代碼覆蓋率常常被拿來(lái)作為衡量測(cè)試好壞的指標(biāo)，甚至，用代碼覆蓋率來(lái)考核測(cè)試任務(wù)完成情況，比如，代碼覆蓋率必須達(dá)到80％或 90％。于是乎，測(cè)試人員費(fèi)盡心思設(shè)計(jì)案例覆蓋代碼。用代碼覆蓋率來(lái)衡量，有利也有有弊。

首先，讓我們先來(lái)了解一下所謂的“代碼覆蓋率”。我找來(lái)了所謂的定義：

代碼覆蓋率 ＝ 代碼的覆蓋程度，一種度量方式。

關(guān)于如何開(kāi)發(fā)組件庫(kù)，可看這篇：

如何基于vue開(kāi)發(fā)ui組件庫(kù)（heaven-ui）

單元測(cè)試

英文叫 Unit Testing，又稱為模塊測(cè)試，是針對(duì)程序模塊來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作。程序單元是應(yīng)用的最小可測(cè)試部件。在過(guò)程化編程中，一個(gè)單元就是單個(gè)程序、函數(shù)、過(guò)程等；對(duì)于面向?qū)ο缶幊蹋钚卧褪欠椒?，包括基?lèi)（超類(lèi)）、抽象類(lèi)、或者派生類(lèi)（子類(lèi)）中的方法。

需要注意以下幾種情況：

1. 需要訪問(wèn)數(shù)據(jù)庫(kù)的測(cè)試不叫單元測(cè)試；
2. 需要訪問(wèn)網(wǎng)絡(luò)的測(cè)試不叫單元測(cè)試；
3. 需要訪問(wèn)文件系統(tǒng)的測(cè)試不叫單元測(cè)試。

雖然編寫(xiě)單元測(cè)試的過(guò)程很繁瑣，但不得不說(shuō)，它對(duì)于我們的組件的迭代有很大的幫助。

比如寫(xiě)單元測(cè)試的時(shí)候，經(jīng)常會(huì)發(fā)生輸出結(jié)果不符合你預(yù)期的結(jié)果，這時(shí)你就得重新審視你的代碼了。

組件庫(kù)中每一個(gè)組件都可能會(huì)重構(gòu)或者更新迭代，如果單元測(cè)試覆蓋率高的話，修改代碼之后就越可能會(huì)發(fā)現(xiàn)潛在的問(wèn)題。比如某些功能代碼不小心刪掉了。這樣會(huì)導(dǎo)致用戶更新最新版本時(shí)，缺少了之前使用過(guò)的功能，產(chǎn)生一些疑惑。

技術(shù)選型

單元測(cè)試用到的工具大致分為三部分：分別為管理工具、測(cè)試框架、斷言庫(kù)。

測(cè)試框架市面上有很多種，常用的測(cè)試框架有以下幾種：

• Jasmine：Behavior-Drive development(BDD)風(fēng)格的測(cè)試框架，在業(yè)內(nèi)較為流行,功能很全面，自帶 asssert、mock 功能

• Qunit：該框架誕生之初是為了 jquery 的單元測(cè)試，后來(lái)獨(dú)立出來(lái)不再依賴于 jquery 本身，但是其身上還是脫離不開(kāi) jquery 的影子

• Mocha：Mocha 是一個(gè)功能豐富的前端測(cè)試框架。所謂"測(cè)試框架"，就是運(yùn)行測(cè)試的工具。通過(guò)它，可以為 JavaScript 應(yīng)用添加測(cè)試用例，從而保證代碼的質(zhì)量。Mocha 既可以基于 Node.js 環(huán)境運(yùn)行也可以在瀏覽器環(huán)境運(yùn)行。

• Jest：來(lái)自于 facebook 出品的通用測(cè)試框架，Jest 是一個(gè)令人愉快的 JavaScript 測(cè)試框架，專注于簡(jiǎn)潔明快。他適用但不局限于使用以下技術(shù)的項(xiàng)目：Babel, TypeScript, Node, React, Angular, Vue

這里 我選用的是Karma、Mocha 和 Chai，接下來(lái)簡(jiǎn)單介紹一下我使用的（Karma）管理工具和（Chai）斷言庫(kù)

• Karma 是一個(gè)基于 Node.js 的 JavaScript 測(cè)試執(zhí)行過(guò)程管理工具，又稱 Test Runner。常用的管理工具還有 Jest 等。

• Chai 是一個(gè)斷言庫(kù)，類(lèi)似于 Node 的內(nèi)置斷言。通過(guò)提供許多可以針對(duì)代碼運(yùn)行的斷言，它使測(cè)試變得更加容易。

• Karma 是一個(gè)基于 Node.js 的 JavaScript 測(cè)試執(zhí)行過(guò)程管理工具，又稱 Test Runner。常用的管理工具還有 Jest 等。

• Chai 是一個(gè)斷言庫(kù)，類(lèi)似于 Node 的內(nèi)置斷言。通過(guò)提供許多可以針對(duì)代碼運(yùn)行的斷言，它使測(cè)試變得更加容易。

編寫(xiě)測(cè)試用例

組件庫(kù)開(kāi)發(fā)調(diào)試完成后，我們需要編寫(xiě)每個(gè)組件對(duì)應(yīng)的單元測(cè)試，以達(dá)到100%的覆蓋率為?標(biāo)。

我在組件庫(kù)中選擇的是karma,目錄結(jié)構(gòu)如下：

image.png

spec目錄就是對(duì)應(yīng)組件的單元測(cè)試用例了

以button為例：

test/specs/Button.spec.js

import Vue from 'vue'
import Button from '@/components/button'

describe('button.vue', () => {
  it('button是否存在',()=>{
    expect(Button).to.be.ok;
  })
  it('測(cè)試name是否生效', () => {
    const Constructor = Vue.extend(Button)
    const vm = new Constructor().$mount()
    expect(vm.$el.querySelector('.hello h1').textContent)
      .to.equal('Welcome to Your Vue.js App')
  })
})

執(zhí)行上述的單元測(cè)試代碼，就能證明這段代碼的行為輸出的結(jié)果，是否和我們期望的一致。

為什么要做單元測(cè)試

為達(dá)到100%的覆蓋率，我們必須盡快能的覆蓋所有場(chǎng)景。不得不說(shuō)，編寫(xiě)測(cè)試用例比較繁瑣，但我們又為什么要做這繁瑣的工作呢？

因?yàn)閱卧獪y(cè)試包含以下優(yōu)點(diǎn)：

1. 可能會(huì)測(cè)出功能的隱藏bug

2. 保證代碼重構(gòu)的安全性。

3. 組件庫(kù)中每?個(gè)組件都可能會(huì)重構(gòu)或者更新迭代，如果單元測(cè)試覆蓋率?的話，修改代碼之后就越可能會(huì)發(fā)現(xiàn)潛在的問(wèn)題。?如版本升級(jí)后，導(dǎo)致某部分功能的缺失。

4. 自動(dòng)檢測(cè)，可以做到一次編寫(xiě)，多次運(yùn)行，節(jié)省重復(fù)測(cè)試的時(shí)間

所以對(duì)于現(xiàn)在的組件庫(kù)項(xiàng)目項(xiàng)目，能夠被后續(xù)的開(kāi)發(fā)者理解并且參照著繼續(xù)維護(hù)下去，那么單元測(cè)試是非常必要的。

原文鏈接：
如何做組件庫(kù)的單元測(cè)試