NutUI 3.0 中單元測試的探索和實踐

時間 2020-05-31

標籤 nutui 3.0 單元測試探索實踐简体版

原文原文鏈接

衆所周知，單元測試功能，是組件庫開發中必不可少的一部分，負責進行檢查和驗證，保證了組件的合理性和規範性。本文主要講的就是單元測試在 NUTUI 組件庫中的探索實踐，咱們將從如何編寫單元測試、持續集成服務、Coveralls 自動測試代碼覆蓋率三方面進行闡述。如圖所示：css

若是你對這些內容感興趣，就和我一塊兒來看一下吧！html

單元測試配置

在進入單元測試配置正文以前，咱們先來了解下面兩個問題。vue

單元測試是什麼？
爲何須要單元測試？

單元測試是什麼？

單元測試（unit testing），能夠對軟件中的最小可測試單元進行檢查和驗證，是軟件開發中重要的一部分。它使得添加新功能和追蹤問題更加容易。node

爲何須要單元測試？

單元測試在開發的時候頗有用，即能幫助開發者思考如何設計一個組件，也可以重構一個現有組件。每次代碼發生變化的時候它們都會被運行。有了單元測試，咱們能夠自信的交付本身的代碼，而沒有任何的後顧之憂。組件的單元測試有如下等優勢：webpack

提供描述組件行爲的文檔
減小調試時間，節省手動測試的時間
減小研發新特性時產生的 bug，測出功能的隱藏 bug
減小和快速定位 bug
促進重構，保證代碼重構的安全性

如何編寫單元測試？

咱們既是單元測試的受益者，同時也是開發者，接下來咱們進入正題，來聊一聊，如何在 vue 組件庫中，加入單元測試。單元測試用到的工具大體分爲三部分：測試框架、測試運行器、斷言庫。web

測試框架

由於咱們是 vue 組件庫，因此使用 Vue Test Utils 做爲測試框架，它是 Vue 組件單元測試的官方庫，有詳細的指引和自定義設置用於測試，文檔清晰，容易上手。npm

咱們將其做爲開發依賴安裝在項目中：json

npm install --save-dev @vue/test-utils瀏覽器

它依賴瀏覽器環境，能夠運行在真實的瀏覽器或是 Node 虛擬瀏覽器中，由於在不一樣的平臺上啓動真實的瀏覽器是比較複雜的。因此咱們讓其運行在 Node 虛擬瀏覽器中，這就須要藉助 JSDOM 幫助咱們讓它在 Node 虛擬瀏覽器環境運行測試。sass

咱們把 JSDOM 作爲開發依賴安裝：

npm install --save-dev jsdom jsdom-global

而後在項目根目錄建立 /test 的空文件夾，建立 setup.js 文件

require('jsdom-global')()

在測試入口處使用 jsdom-global 手動設置 JSDOM 便可。這樣每次運行單元測試都會執行 setup.js 文件，從而引入 JSDOM。

測試運行器

測試運行器（test runner）就是運行測試的程序。測試運行器不少，Vue Test Utils 基本上能夠支持主流 JavaScript 測試運行器。比較好的是，Vue Test Utils 幫咱們篩選了一遍，推薦了兩個測試運行器給咱們，咱們從中選擇一個便可，

Jest: 功能最全的測試運行器。它所需的配置是最少的，默認安裝了 JSDOM，內置斷言且命令行的用戶體驗很是好。
mocha-webpack: webpack + Mocha 的包裹器，包含順暢的接口和偵聽模式。

測試單文件組件的策略是經過 webpack 編譯全部的測試文件，而後在測試運行器中運行，使用 mocha-webpack 好處在於咱們可以經過 webpack + vue-loader 獲得完整的單文件組件支持，咱們沒必要對源代碼作任何妥協，雖然 Jest 也提供了vue-jest 預處理器來處理最多見的單文件組件，但仍不是 vue-loader 100% 的功能。因此咱們選用了 mocha-webpack。

經過 npm 安裝 mocha、mocha-webpack：

npm install --save-dev mocha mocha-webpack

須要注意的是，mocha-webpack 依賴 webpack 和 mocha，而且對版本有要求 webpack 版本須要4.x.x，mocha 版本爲4.x.x & 5.x.x。

斷言庫

咱們使用 mocha 進行測試的時候，須要結合斷言庫去使用，Mocha 不像 Jest 框架同樣有內置的斷言庫。它容許咱們本身選擇合適的斷言庫。expect 是一款斷言庫，它極簡的 BDD 風格，獲得不少測試框架的承認，這些測試框架內置的也是 expect 斷言庫，所以咱們本次也使用了 expect 斷言庫。

首先安裝開發依賴：

$ npm install --save-dev expect

並在 test/setup.js 中寫入：

global.expect = require('expect')

令其全局可用，這樣就不須要在每一個測試文件裏導入它了。

安裝好了各類開發依賴以後，在根目錄 package.json 文件中定義定義一個 npm 腳本 test 命令

{
    ...
    "scripts": {
        ...
        "test": "cross-env NODE_ENV=test mocha-webpack --webpack-config dist_cli/webpack/test.config.js --require dist_cli/test/setup.js src/packages/*/__test__/**.spec.js"
    },
    ...
}
複製代碼

值得注意的是，若是項目沒有安裝 cross-env，須要先安裝一下，它用於跨平臺設置環境變量。簡單來了解一下 test 命令參數的含義：

--webpack-config：指定了該測試使用的 webpack 配置文件。
--require：確保了文件 test/setup.js 會在任何測試以前運行，這樣咱們能夠在該文件中設置測試所需的全局環境。
最後一個參數 src/ 目錄：是該測試包所涵蓋的全部測試文件的集合。

準備好以上環境，在命令行執行 npm test 就能夠執行測試。效果以下：

最基本的單元測試已經配置完成，但咱們的工做尚未結束，繼續往下看

增長單元測試代碼覆蓋率

覆蓋率既是度量測試完整性的一個手段，也是測試有效性的一個度量。測試覆蓋是對測試徹底程度的評測。 Mocha 是 JavaScript 項目的測試工具，Istanbul 是 JS 測試覆蓋率報告的生成工具。咱們利用兩者測試代碼並生成代碼庫的測試覆蓋率報告。

nyc 是 Istanbul 的命令行接口，咱們將其做爲開發依賴安裝在項目中：

$ npm install --save-dev nyc 
複製代碼

而後在上面的 npm 腳本增長 nyc

{
    ...
    "scripts": {
        ...
        "test": "cross-env NODE_ENV=test nyc mocha-webpack --webpack-config dist_cli/webpack/test.config.js --require dist_cli/test/setup.js src/packages/*/__test__/**.spec.js"
    },
    ...
}
複製代碼

同時須要在的 package.json 中配置 nyc:

{
    ...
    "nyc": {
    "include": [
        "../../../src/packages/**/*.vue"
    ],
    "reporter": [
        "lcov",
        "text"
    ],
    "instrument": false,
    "sourceMap": false
    },
    ...
}
複製代碼

介紹一下參數的含義：

include: 測試文件路徑
reporter: 輸出 lcov (lcov.info + html 報告)和文本形式的覆蓋率報告
instrument 和 sourceMap: 設置爲 false，禁用 nyc 去 instrumenting 和 sourceMap 你的代碼，後續咱們指定 loader 去完成。

這時咱們運行 npm test 命令, 就能夠得到代碼庫的測試覆蓋率報告。

如圖所示，出現了多個 Unknow，顯然還有一些問題，須要安裝一下 istanbul-instrumenter-loader，而後把 loader 加到咱們的 test.config.ts 的配置文件中。再把生成環境的配置文件 package.conf.ts 導入 merge 進去。

import { ROOT_PACKAGE_PATH } from '../common/dic';
import { packageConfig } from './package.config';
import merge from 'webpack-merge';
module.exports =  merge(packageConfig(false), {
    module: {
        rules: [
            {
                test: /\.(js|ts)/,
                use: {
                    loader: 'istanbul-instrumenter-loader',
                    options: { esModules: true }
                },
                include: [ROOT_PACKAGE_PATH('src/packages')]
            },
            {
                test: /\.css$/,
                use: [
                    'style-loader',
                    'css-loader', 
                ]
            },
            {
                test: /\.scss$/,
                use: [
                    'style-loader',
                    'css-loader',
                    {
                        loader: 'sass-loader',
                        options: { 
                            prependData: `@import "@/styles/index.scss"; `
                        }
                    }
                ]
            }
        ],
    },
    devtool: 'inline-cheap-module-source-map',
    externals: [require('webpack-node-externals')()] // 忽略node_modules文件夾中的全部模塊
});

複製代碼

至此，整個項目的代碼覆蓋率統計配置基本完成，值得注意的是 istanbul-instrumenter-loader 須要放在最上面，保證它最後執行，這時咱們在終端執行 npm test 會顯示測試覆蓋率結果。

同時，在項目根目錄，會自動建立 coverage 文件夾，裏面有生成測試覆蓋率報告文件 (Icov.info+html)。

接下來咱們還要介紹一下持續集成服務

持續集成服務

持續集成指的是隻要代碼有變動，就自動運行構建和測試，反饋運行結果。確保符合預期以後，再將新代碼集成到主幹, 有助於提升項目質量。經過持續集成能夠自動編譯、打包、簽名項目，配合單元測試能夠實現持續集成+自動化測試。咱們的項目維護在 Github 上。Github 有個好朋友 Travis CI，是一個在線託管的分佈式持續集成服務，咱們能夠用它來構建並測試託管在 Github 上的軟件項目。你能夠輕鬆用 Travis CI 同步你的 Github 項目，而且你能夠在幾分鐘內就能測試你的項目。

值得注意的是，Travis CI 分爲免費和自費的，對於咱們 Github 上的開源項目，直接能夠用免費的，訪問免費版便可。

下面來看一下怎麼讓本身的 Github 項目用 Travis CI 測試。

首先，訪問 Travis CI 並使用項目的 Github 帳戶登陸。登陸以後，表明你的 Github 對 Travis 進行了受權，Travis 能夠訪問你的 Github 上全部代碼倉庫。選擇須要 Travis CI 幫你持續集成的倉庫，點擊右側的激活開關便可。這樣Travis CI 就會幫你監聽這個倉庫的全部變化自動構建，完成預約的操做。

接下來，咱們須要在咱們代碼倉庫的根目錄添加一個 .travis.yml 文件，來告訴 Travis CI 定義預約的命令，它會告訴 Travis CI 作什麼，怎麼作。配置以下內容，可按需更改：

sudo: required
language: node_js
node_js:
- '8'
script:
- npm test
- npm run coveralls
複製代碼

Travis 的運行流程很簡單，包含兩個階段：install（安裝依賴）和 script（執行腳本）。對於 Node 項目來講，install 和 script 階段都有默認腳本，如不須要修改，能夠省略不寫。瞭解一下參數的含義：

sudo: required 表示須要 sudo 權限。
language: 指定了項目的語言，node_js 指定運行環境爲 Node 。
node_js: 指定 Node 版本,可指定多個。
install: 安裝依賴，用來指定安裝腳本，的默認腳本是 npm install
script: 用來指定構建或測試腳本，默認腳本 npm test。

還有不少參數，我就不一一列舉了，具體能夠查看官網配置

完成上面的操做後，push 這個這個文件到你的 Github 倉庫。以後每次往 Github 的該倉庫 push 代碼，Travis 就會去找這個文件，執行配置好的預約義指令了。

這裏能夠看到運行結果，可點擊查看構建過程的詳細信息。如運行有誤，會有以下提示，咱們要知道，script構建階段只要有一個失敗，狀態就會顯示失敗。

以上就是簡單的 Travis CI 和 Github 項目的關聯過程。

Travis CI 確實很給力，若是想在 Github 項目中直接看到 CI 結果徽標，只須要點擊該圖標，選擇 markdown，而後將 result 文本框內容複製到 Github 上的 README.md 文件中便可。

Coveralls自動測試代碼覆蓋率

最後，咱們想要生成一份代碼覆蓋率的報告，這裏須要使用 Coveralls。Coveralls 支持 Github 上的項目，也能夠與 Travis CI集成。訪問 coveralls.io/，使用 Github 帳號登陸，以後點擊上面的 Add Repo，接着將按鈕置爲 ON 狀態

點擊右邊 detail，點擊 detials 進入詳細配置頁面，頁面右側，獲取該項目的 token，根據本身的環境類型編輯相應配置文件在根目錄下添加 .coverall.yml 文件，並添加下面內容：

service_name: travis-ci
repo_token: bOzghLfr6hi9x**************56vdl1YG
複製代碼

給 Coveralls 上傳的測試報告須要有統一的 lcov 格式，上文中咱們有對 nyc 進行配置，在根目錄 coverage 文件夾中生成 lcov.info 在 package.json 文件的 scripts 字段添加下面這行命令

"coveralls": "cat ./coverage/lcov.info | coveralls",
複製代碼

push 代碼到Github倉庫。一樣，咱們能夠獲取一個測試覆蓋率的徽標，進入剛纔的詳情配置頁。點擊按鈕複製 markdown 內容到 Github 上的 README.md 文件中便可。

總結

單元測試功能已集成在由咱們團隊開發的 NUTUI 組件庫上面進行實踐，NutUI 是一套京東風格的移動端Vue組件庫，開發和服務於移動 Web 界面的企業級前中後臺產品。經過 NutUI，能夠快速搭建出風格統一的頁面，提高開發效率。目前已有近 50 個組件，這些組件被普遍使用於京東的各個移動端業務中。後期咱們會對整個 NutUI 系統架構進行革新，將整個組件庫構建工具抽離出，採用 WebPack Node API構建，對編譯作出更細粒度的控制，同時加大對編譯配置的優化調整，大幅提升性能和減小打包文件體積，提供獨立構建的 NutUI-CLI。單元測試的功能也保證了組件的規範化，減小錯誤。歡迎各位使用，如在使用中有任何問題，咱們也會及時反饋跟進。流年笑擲，將來可期～