前言
在我們開發(fā)完一個組件庫的后瓷叫，在做單元測試時，代碼覆蓋率常常被拿來作為衡量測試好壞的指標，甚至室抽，用代碼覆蓋率來考核測試任務完成情況妆毕，比如株汉，代碼覆蓋率必須達到80％或 90％危号。于是乎洞难，測試人員費盡心思設計案例覆蓋代碼。用代碼覆蓋率來衡量援所，有利也有有弊咧七。
首先，讓我們先來了解一下所謂的“代碼覆蓋率”任斋。我找來了所謂的定義：
代碼覆蓋率 ＝ 代碼的覆蓋程度，一種度量方式耻涛。
關于如何開發(fā)組件庫废酷，可看這篇：
單元測試
英文叫 Unit Testing，又稱為模塊測試抹缕，是針對程序模塊來進行正確性檢驗的測試工作澈蟆。程序單元是應用的最小可測試部件。在過程化編程中卓研，一個單元就是單個程序趴俘、函數、過程等奏赘；對于面向對象編程寥闪，最小單元就是方法，包括基類（超類）磨淌、抽象類疲憋、或者派生類（子類）中的方法。
需要注意以下幾種情況：
- 需要訪問數據庫的測試不叫單元測試梁只；
- 需要訪問網絡的測試不叫單元測試缚柳；
- 需要訪問文件系統(tǒng)的測試不叫單元測試埃脏。
雖然編寫單元測試的過程很繁瑣，但不得不說秋忙，它對于我們的組件的迭代有很大的幫助彩掐。
比如寫單元測試的時候，經常會發(fā)生輸出結果不符合你預期的結果灰追，這時你就得重新審視你的代碼了堵幽。
組件庫中每一個組件都可能會重構或者更新迭代，如果單元測試覆蓋率高的話监嗜，修改代碼之后就越可能會發(fā)現潛在的問題谐檀。比如某些功能代碼不小心刪掉了。這樣會導致用戶更新最新版本時裁奇，缺少了之前使用過的功能桐猬，產生一些疑惑。
技術選型
單元測試用到的工具大致分為三部分：分別為管理工具刽肠、測試框架溃肪、斷言庫。
測試框架市面上有很多種音五，常用的測試框架有以下幾種：
Jasmine：Behavior-Drive development(BDD)風格的測試框架惫撰，在業(yè)內較為流行,功能很全面，自帶 asssert躺涝、mock 功能
Qunit：該框架誕生之初是為了 jquery 的單元測試厨钻，后來獨立出來不再依賴于 jquery 本身，但是其身上還是脫離不開 jquery 的影子
Mocha：Mocha 是一個功能豐富的前端測試框架坚嗜。所謂"測試框架"夯膀，就是運行測試的工具。通過它苍蔬，可以為 JavaScript 應用添加測試用例诱建，從而保證代碼的質量。Mocha 既可以基于 Node.js 環(huán)境運行也可以在瀏覽器環(huán)境運行碟绑。
Jest：來自于 facebook 出品的通用測試框架俺猿，Jest 是一個令人愉快的 JavaScript 測試框架，專注于簡潔明快格仲。他適用但不局限于使用以下技術的項目：Babel, TypeScript, Node, React, Angular, Vue
這里 我選用的是Karma押袍、Mocha 和 Chai，接下來簡單介紹一下我使用的（Karma）管理工具和（Chai）斷言庫
Karma 是一個基于 Node.js 的 JavaScript 測試執(zhí)行過程管理工具凯肋，又稱 Test Runner伯病。常用的管理工具還有 Jest 等。
Chai 是一個斷言庫，類似于 Node 的內置斷言午笛。通過提供許多可以針對代碼運行的斷言惭蟋，它使測試變得更加容易。
Karma 是一個基于 Node.js 的 JavaScript 測試執(zhí)行過程管理工具药磺，又稱 Test Runner告组。常用的管理工具還有 Jest 等。
Chai 是一個斷言庫癌佩，類似于 Node 的內置斷言木缝。通過提供許多可以針對代碼運行的斷言，它使測試變得更加容易围辙。
編寫測試用例
組件庫開發(fā)調試完成后我碟，我們需要編寫每個組件對應的單元測試，以達到100%的覆蓋率為?標姚建。
我在組件庫中選擇的是karma,目錄結構如下：
spec目錄就是對應組件的單元測試用例了
以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('測試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í)行上述的單元測試代碼矫俺，就能證明這段代碼的行為輸出的結果，是否和我們期望的一致掸冤。
為什么要做單元測試
為達到100%的覆蓋率厘托，我們必須盡快能的覆蓋所有場景。不得不說稿湿，編寫測試用例比較繁瑣铅匹，但我們又為什么要做這繁瑣的工作呢？
因為單元測試包含以下優(yōu)點：
可能會測出功能的隱藏bug
保證代碼重構的安全性饺藤。
組件庫中每?個組件都可能會重構或者更新迭代包斑，如果單元測試覆蓋率?的話，修改代碼之后就越可能會發(fā)現潛在的問題涕俗。?如版本升級后舰始，導致某部分功能的缺失。
自動檢測咽袜，可以做到一次編寫，多次運行枕稀，節(jié)省重復測試的時間
所以對于現在的組件庫項目項目询刹，能夠被后續(xù)的開發(fā)者理解并且參照著繼續(xù)維護下去，那么單元測試是非常必要的萎坷。
原文鏈接：
如何做組件庫的單元測試
