4招了解前端單元測(cè)試

隨著每個(gè)工程的復(fù)雜化、代碼的高復(fù)用性要求和前端代碼模塊之間的高內(nèi)聚低耦合的需求，前端工程中的單元測(cè)試流程就顯得很有其必要。

1.前端單元測(cè)試是什么

首先我們要明確測(cè)試是什么：

為檢測(cè)特定的目標(biāo)是否符合標(biāo)準(zhǔn)而采用專用的工具或者方法進(jìn)行驗(yàn)證，并最終得出特定的結(jié)果。

對(duì)于前端開發(fā)過程來說，這里的特定目標(biāo)就是指我們寫的代碼，而工具就是我們需要用到的測(cè)試框架(庫(kù))、測(cè)試用例等。檢測(cè)處的結(jié)果就是展示測(cè)試是否通過或者給出測(cè)試報(bào)告，這樣才能方便問題的排查和后期的修正。

基于測(cè)試“是什么”的說法，為便于剛從事前端開發(fā)的同行的進(jìn)階理解，那我們就列出單元測(cè)試它“不是什么”：

需要訪問數(shù)據(jù)庫(kù)的測(cè)試不是單元測(cè)試

需要訪問網(wǎng)絡(luò)的測(cè)試不是單元測(cè)試

需要訪問文件系統(tǒng)的測(cè)試不是單元測(cè)試

--- 修改代碼的藝術(shù)

對(duì)于單元測(cè)試“不是什么”的引用解釋，至此點(diǎn)到為止。鑒于篇幅限制，對(duì)于引用內(nèi)容，我想前端開發(fā)的同行們看到后會(huì)初步有一個(gè)屬于自己的理解。

2.單元測(cè)試的意義以及為什么需要單元測(cè)試

2.1 單元測(cè)試的意義

對(duì)于現(xiàn)在的前端工程，一個(gè)標(biāo)準(zhǔn)完整的項(xiàng)目，測(cè)試是非常有必要的。很多時(shí)候我們只是完成了項(xiàng)目而忽略了項(xiàng)目測(cè)試的部分，測(cè)試的意義主要在于下面幾點(diǎn)：

  1. TDD（測(cè)試驅(qū)動(dòng)開發(fā)） 被證明是有效的軟件編寫原則，它能覆蓋更多的功能接口。
  2. 快速反饋你的功能輸出，驗(yàn)證你的想法。
  3. 保證代碼重構(gòu)的安全性，沒有一成不變的代碼，測(cè)試用例能給你多變的代碼結(jié)構(gòu)一個(gè)定心丸。
  4. 易于測(cè)試的代碼，說明是一個(gè)好的設(shè)計(jì)。做單元測(cè)試之前，肯定要實(shí)例化一個(gè)東西，假如這個(gè)東西有很多依賴的話，這個(gè)測(cè)試構(gòu)7. 造過程將會(huì)非常耗時(shí)，會(huì)影響你的測(cè)試效率，怎么辦呢？要依賴分離，一個(gè)類盡量保證功能單一，比如視圖與功能分離，這樣的話，你的代碼也便于維護(hù)和理解。
2.2 為什么需要單元測(cè)試
  1. 首先是一個(gè)前端單元測(cè)試的根本性原由：JavaScript 是動(dòng)態(tài)語(yǔ)言，缺少類型檢查，編譯期間無法定位到錯(cuò)誤; JavaScript 宿主的兼容性問題。比如 DOM 操作在不同瀏覽器上的表現(xiàn)。
  2. 正確性：測(cè)試可以驗(yàn)證代碼的正確性，在上線前做到心里有底。
  3. 自動(dòng)化：當(dāng)然手工也可以測(cè)試，通過console可以打印出內(nèi)部信息，但是這是一次性的事情，下次測(cè)試還需要從頭來過，效率不能得到保證。通過編寫測(cè)試用例，可以做到一次編寫，多次運(yùn)行。
  4. 解釋性：測(cè)試用例用于測(cè)試接口、模塊的重要性，那么在測(cè)試用例中就會(huì)涉及如何使用這些API。其他開發(fā)人員如果要使用這些API，那閱讀測(cè)試用例是一種很好地途徑，有時(shí)比文檔說明更清晰。
  5. 驅(qū)動(dòng)開發(fā)，指導(dǎo)設(shè)計(jì)：代碼被測(cè)試的前提是代碼本身的可測(cè)試性，那么要保證代碼的可測(cè)試性，就需要在開發(fā)中注意API的設(shè)計(jì)，TDD將測(cè)試前移就是起到這么一個(gè)作用。
  6. 保證重構(gòu)：互聯(lián)網(wǎng)行業(yè)產(chǎn)品迭代速度很快，迭代后必然存在代碼重構(gòu)的過程，那怎么才能保證重構(gòu)后代碼的質(zhì)量呢？有測(cè)試用例做后盾，就可以大膽的進(jìn)行重構(gòu)。

3.如何寫單元測(cè)試用例

3.1 原則
  • 測(cè)試代碼時(shí)，只考慮測(cè)試，不考慮內(nèi)部實(shí)現(xiàn)
  • 數(shù)據(jù)盡量模擬現(xiàn)實(shí)，越靠近現(xiàn)實(shí)越好
  • 充分考慮數(shù)據(jù)的邊界條件
  • 對(duì)重點(diǎn)、復(fù)雜、核心代碼，重點(diǎn)測(cè)試
  • 利用AOP(beforeEach、afterEach),減少測(cè)試代碼數(shù)量，避免無用功能
  • 測(cè)試、功能開發(fā)相結(jié)合，有利于設(shè)計(jì)和代碼重構(gòu)
3.2 兩個(gè)常用的單元測(cè)試方法論

在單元測(cè)試中，常用的方法論有兩個(gè)：TDD（測(cè)試驅(qū)動(dòng)開發(fā)）&BDD（行為驅(qū)動(dòng)開發(fā)）

3.3 相信你看完之后也有一個(gè)自己對(duì)TDD和BDD的個(gè)人觀點(diǎn)，在此我先談?wù)勎覍?duì)TDD和BDD的理解：

TDD（Test-driven development）：

其基本思路是通過測(cè)試來推動(dòng)整個(gè)開發(fā)的進(jìn)行。

  • 單元測(cè)試的首要目的不是為了能夠編寫出大覆蓋率的全部通過的測(cè)試代碼，而是需要從使用者(調(diào)用者)的角度出發(fā)，嘗試函數(shù)邏輯的各種可能性，進(jìn)而輔助性增強(qiáng)代碼質(zhì)量

  • 測(cè)試是手段而不是目的。測(cè)試的主要目的不是證明代碼正確，而是幫助發(fā)現(xiàn)錯(cuò)誤，包括低級(jí)的錯(cuò)誤

  • 測(cè)試要快?？焖龠\(yùn)行、快速編寫

  • 測(cè)試代碼保持簡(jiǎn)潔

  • 不會(huì)忽略失敗的測(cè)試。一旦團(tuán)隊(duì)開始接受1個(gè)測(cè)試的構(gòu)建失敗，那么他們漸漸地適應(yīng)2、3、4或者更多的失敗。在這種情況下，測(cè)試集就不再起作用

需要注意的是：

  • 一定不能誤解了TDD的核心目的！

  • 測(cè)試不是為了覆蓋率和正確率

  • 而是作為實(shí)例，告訴開發(fā)人員要編寫什么代碼

  • 紅燈（代碼還不完善，測(cè)試掛）-> 綠燈（編寫代碼，測(cè)試通過）-> 重構(gòu)（優(yōu)化代碼并保證測(cè)試通過）

TDD的過程是：

  1. 需求分析，思考實(shí)現(xiàn)?？紤]如何“使用”產(chǎn)品代碼，是一個(gè)實(shí)例方法還是一個(gè)類方法，是從構(gòu)造函數(shù)傳參還是從方法調(diào)用傳參，方法的命名，返回值等。這時(shí)其實(shí)就是在做設(shè)計(jì)，而且設(shè)計(jì)以代碼來體現(xiàn)。此時(shí)測(cè)試為紅

  2. 實(shí)現(xiàn)代碼讓測(cè)試為”綠燈“

  3. 重構(gòu)，然后重復(fù)測(cè)試

  4. 最終符合所有要求即：

    • 每個(gè)概念都被清晰的表達(dá)

    • 代碼中無自我重復(fù)

    • 沒有多余的東西

    • 通過測(cè)試

BDD(Behavior-driven development)：

行為驅(qū)動(dòng)開發(fā)（BDD），重點(diǎn)是通過與利益相關(guān)者（簡(jiǎn)單說就是客戶）的討論，取得對(duì)預(yù)期的軟件行為的認(rèn)識(shí)，其重點(diǎn)在于溝通

BDD過程是：

  1. 從業(yè)務(wù)的角度定義具體的，以及可衡量的目標(biāo)

  2. 找到一種可以達(dá)到設(shè)定目標(biāo)的、對(duì)業(yè)務(wù)最重要的那些功能的方法

  3. 然后像故事一樣描述出一個(gè)個(gè)具體可執(zhí)行的行為。其描述方法基于一些通用詞匯，這些詞匯具有準(zhǔn)確無誤的表達(dá)能力和一致的含義。例如，expect, should, assert

  4. 尋找合適語(yǔ)言及方法，對(duì)行為進(jìn)行實(shí)現(xiàn)

  5. 測(cè)試人員檢驗(yàn)產(chǎn)品運(yùn)行結(jié)果是否符合預(yù)期行為。最大程度的交付出符合用戶期望的產(chǎn)品，避免表達(dá)不一致帶來的問題

4. Mocha/Karma+Travis.CI的前端測(cè)試工作流

以上內(nèi)容從什么是單元測(cè)試談到單元測(cè)試的方法論。那么怎樣用常用框架進(jìn)行單元測(cè)試？單元測(cè)試的工具環(huán)境是什么？單元測(cè)試的實(shí)際示例是怎樣的？

首先應(yīng)該簡(jiǎn)單介紹一下Mocha、Karma和Travis.CI

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

Karma：一個(gè)基于Node.js的JavaScript測(cè)試執(zhí)行過程管理工具（Test Runner）。該工具可用于測(cè)試所有主流Web瀏覽器，也可集成到CI（Continuous integration）工具，也可和其他代碼編輯器一起使用。這個(gè)測(cè)試工具的一個(gè)強(qiáng)大特性就是，它可以監(jiān)控文件的變化，然后自行執(zhí)行，通過console.log顯示測(cè)試結(jié)果。Karma的一個(gè)強(qiáng)大特性就是，它可以監(jiān)控一套文件的變換，并立即開始測(cè)試已保存的文件，用戶無需離開文本編輯器。測(cè)試結(jié)果通常顯示在命令行中，而非代碼編輯器。這也就讓 Karma 基本可以和任何 JS 編輯器一起使用。

Travis.CI：提供的是持續(xù)集成服務(wù)（Continuous Integration，簡(jiǎn)稱 CI）。它綁定 Github 上面的項(xiàng)目，只要有新的代碼，就會(huì)自動(dòng)抓取。然后，提供一個(gè)運(yùn)行環(huán)境，執(zhí)行測(cè)試，完成構(gòu)建，還能部署到服務(wù)器。

持續(xù)集成指的是只要代碼有變更，就自動(dòng)運(yùn)行構(gòu)建和測(cè)試，反饋運(yùn)行結(jié)果。確保符合預(yù)期以后，再將新代碼"集成"到主干。

持續(xù)集成的好處在于，每次代碼的小幅變更，就能看到運(yùn)行結(jié)果，從而不斷累積小的變更，而不是在開發(fā)周期結(jié)束時(shí)，一下子合并一大塊代碼。

斷言庫(kù)

基本工具框架介紹完畢后，相信稍微了解點(diǎn)測(cè)試的同行都知道，做單元測(cè)試是需要寫測(cè)試腳本的，那么測(cè)試腳本就需要用到斷言庫(kù)。”斷言“，個(gè)人理解即為”用彼代碼斷定測(cè)試此代碼的正確性，檢驗(yàn)并暴露此代碼的錯(cuò)誤?！澳敲磳?duì)于前端單元測(cè)試來說，有以下常用斷言庫(kù)：

看一段代碼示例：

expect(add(1, 1)).to.be.equal(2);

這是一句斷言代碼。

所謂"斷言"，就是判斷源碼的實(shí)際執(zhí)行結(jié)果與預(yù)期結(jié)果是否一致，如果不一致就拋出一個(gè)錯(cuò)誤。上面這句斷言的意思是，調(diào)用 add(1, 1)，結(jié)果應(yīng)該等于 2。所有的測(cè)試用例（it 塊）都應(yīng)該含有一句或多句的斷言。它是編寫測(cè)試用例的關(guān)鍵。斷言功能由斷言庫(kù)來實(shí)現(xiàn)，Mocha 本身不帶斷言庫(kù)，所以必須先引入斷言庫(kù)。

引入斷言庫(kù)代碼示例：

var expect = require('chai').expect;

斷言庫(kù)有很多種，Mocha 并不限制使用哪一種，它允許你使用你想要的任何斷言庫(kù)。上面代碼引入的斷言庫(kù)是 chai，并且指定使用它的 expect 斷言風(fēng)格。下面這些常見的斷言庫(kù):

此處主要介紹一下node assert中常用的API

  • assert(value[, message])
  • assert.ok(value[, message])
  • assert.equal(actual, expect[, message])
  • assert.notEqual(actual, expected[, message])
  • assert.strictEqual(actual, expect[, message])
  • assert.notStrictEqual(actial, expected[, message])
  • assert.deepEqual(actual, expect[, message])
  • assert.notDeepEqual(actual, expected[, message])
  • assert.deepStrictEqual(actual, expect[, message])
  • assert.notDeepStrictEqual(actual, expected[, message])
  • assert.throws(block[, error][, message])
  • assert.doesNotThrow(block[, error][, message])

assert(value[, message])

斷言 value 的值是否為true，這里的等于判斷使用的是 == 而不是 ===。message 是斷言描述，為可選參數(shù)。

const assert = require('assert');
assert(true);

assert.ok(value[, message])

使用方法同 assert(value[, message])。

assert.equal(actual, expect[, message])

預(yù)期 actual 與 expect值相等。equal用于比較的 actual 和 expect 是基礎(chǔ)類型(string, number, boolearn, null, undefined)的數(shù)據(jù)。其中的比較使用的是 == 而不是 ===。

it('assert.equal', () => {
  assert.equal(null, false, 'null compare with false');  // 報(bào)錯(cuò)
  assert.equal(null, true, 'null compare with true');  // 報(bào)錯(cuò)
  assert.equal(undefined, false, 'undefined compare with false'); // 報(bào)錯(cuò)
  assert.equal(undefined, true, 'undefined compare with true'); // 報(bào)錯(cuò)
  assert.equal('', false, '"" compare with false');  // 正常
})

notEqual(actual, expected[, message])

用法同 assert.equal(actual, expect[, message]) 只是對(duì)預(yù)期結(jié)果取反（即不等于）。

assert.strictEqual(actual, expect[, message])

用法同 assert.equal(actual, expect[, message]) 但是內(nèi)部比較是使用的是 === 而不是 ==。

assert.notStrictEqual(actial, expected[, message])

用法同 assert.strictEqual(actual, expect[, message]) 只是對(duì)預(yù)期結(jié)果取反（即不嚴(yán)格等于）。

it('assert.strictEqual', () => {
  assert.strictEqual('', false); // 報(bào)錯(cuò)
})

assert.deepEqual(actual, expect[, message])

deepEqual 方法用于比較兩個(gè)對(duì)象。比較的過程是比較兩個(gè)對(duì)象的 key 和 value 值是否相同, 比較時(shí)用的是 == 而不是 ===。

it('assert.deepEqual', () => {
  const a = { v: 'value' };
  const b = { v: 'value' };
  assert.deepEqual(a, b);
})

assert.notDeepEqual(actual, expected[, message])

用法同 assert.deepEqual(actual, expect[, message]) 只是對(duì)預(yù)期結(jié)果取反（即不嚴(yán)格深等于）。

assert.deepStrictEqual(actual, expect[, message])

用法同 assert.deepEqual(actual, expect[, message]) 但是內(nèi)部比較是使用的是 === 而不是 ==。

assert.notDeepStrictEqual(actual, expected[, message])

用法同 assert.deepStrictEqual(actual, expect[, message]) 只是對(duì)結(jié)果取反（即不嚴(yán)格深等于）。

assert.throws(block[, error][, message])

錯(cuò)誤斷言與捕獲, 斷言指定代碼塊運(yùn)行一定會(huì)報(bào)錯(cuò)或拋出錯(cuò)誤。若代碼運(yùn)行未出現(xiàn)錯(cuò)誤則會(huì)斷言失敗，斷言異常。

it('throws', () => {
  var fun = function() {
    xxx
  };
  assert.throws(fun, 'fun error');
})

assert.doesNotThrow(block[, error][, message])

錯(cuò)誤斷言與捕獲, 用法同 throws 類似，只是和 throws 預(yù)期結(jié)果相反。斷言指定代碼塊運(yùn)行一定不會(huì)報(bào)錯(cuò)或拋出錯(cuò)誤。若代碼運(yùn)行出現(xiàn)錯(cuò)誤則會(huì)斷言失敗，斷言異常。

it('throws', () => {
  var fun = function() {
    xxx
  };
  assert.doesNotThrow(fun, 'fun error');
})

相應(yīng)的工具介紹之后，針對(duì)Mocha、Karma以及Travis.CI的用法談個(gè)人在操作時(shí)的實(shí)踐經(jīng)驗(yàn)。

Mocha

  • 安裝mocha
npm install mocha -g

當(dāng)然也可以在不在全局安裝，只安局部安裝在項(xiàng)目中

npm install mocha --save
  • 創(chuàng)建一個(gè)測(cè)試文件 test.js 
var assert = require('assert')

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      assert.equal(-1, [1, 2, 3].indexOf(-1))
    })
  })
})

這段文件和簡(jiǎn)單就是測(cè)試 Array 的一個(gè) indexOf() 方法。這里我是用的斷言庫(kù)是 Node 所提供的 Assert 模塊里的API。這里斷言 -1 等于 數(shù)組 [1, 2, 3] 執(zhí)行 indexOf(-1)后返回的值，如果測(cè)試通過則不會(huì)報(bào)錯(cuò)，如果有誤就會(huì)報(bào)出錯(cuò)誤。

下面我們使用全局安裝的 mocha 來運(yùn)行一下這個(gè)文件 mocha test.js。
下面是返回結(jié)果

基礎(chǔ)測(cè)試用例實(shí)例

const assert = require('assert');

describe('測(cè)試套件描述', function() {
  it('測(cè)試用例描述: 1 + 2 = 3', function() {
    // 測(cè)試代碼
    const result = 1 + 2;
    // 測(cè)試斷言
    assert.equal(result, 3);
  });
});

Mocha 測(cè)試用例主要包含下面幾部分:

  1. describe 定義的測(cè)試套件(test suite)
  2. it 定義的測(cè)試用例(test case)
  3. 測(cè)試代碼
  4. 斷言部分

說明：每個(gè)測(cè)試文件中可以有多個(gè)測(cè)試套件和測(cè)試用例。mocha不僅可以在node環(huán)境運(yùn)行, 也可以在瀏覽器環(huán)境運(yùn)行；在node中運(yùn)行也可以通過npm i mocha -g全局安裝mocha然后以命令行的方式運(yùn)行測(cè)試用例也是可行的。

這里略微詳細(xì)介紹下測(cè)試腳本寫法

Mocha 的作用是運(yùn)行測(cè)試腳本，首先必須學(xué)會(huì)寫測(cè)試腳本。所謂"測(cè)試腳本"，就是用來測(cè)試源碼的腳本。下面是一個(gè)加法模塊 add.js 的代碼。

// add.js
function add(x, y) {
  return x + y;
}

module.exports = add;

要測(cè)試這個(gè)加法模塊是否正確，就要寫測(cè)試腳本。通常，測(cè)試腳本與所要測(cè)試的源碼腳本同名，但是后綴名為.test.js（表示測(cè)試）或者.spec.js（表示規(guī)格）。比如，add.js 的測(cè)試腳本名字就是 add.test.js。

// add.test.js
var add = require('./add.js');
var expect = require('chai').expect;

describe('加法函數(shù)的測(cè)試', function() {
  it('1 加 1 應(yīng)該等于 2', function() {
    expect(add(1, 1)).to.be.equal(2);
  });
});

上面這段代碼，就是測(cè)試腳本，它可以獨(dú)立執(zhí)行。測(cè)試腳本里面應(yīng)該包括一個(gè)或多個(gè) describe 塊，每個(gè) describe 塊應(yīng)該包括一個(gè)或多個(gè) it 塊。

describe 塊稱為"測(cè)試套件"（test suite），表示一組相關(guān)的測(cè)試。它是一個(gè)函數(shù)，第一個(gè)參數(shù)是測(cè)試套件的名稱（"加法函數(shù)的測(cè)試"），第二個(gè)參數(shù)是一個(gè)實(shí)際執(zhí)行的函數(shù)。

it 塊稱為"測(cè)試用例"（test case），表示一個(gè)單獨(dú)的測(cè)試，是測(cè)試的最小單位。它也是一個(gè)函數(shù)，第一個(gè)參數(shù)是測(cè)試用例的名稱（"1 加 1 應(yīng)該等于 2"），第二個(gè)參數(shù)是一個(gè)實(shí)際執(zhí)行的函數(shù)。

expect 斷言的優(yōu)點(diǎn)是很接近自然語(yǔ)言，下面是一些例子。

// 相等或不相等
expect(4 + 5).to.be.equal(9);
expect(4 + 5).to.be.not.equal(10);
expect(foo).to.be.deep.equal({ bar: 'baz' });

// 布爾值為true
expect('everthing').to.be.ok;
expect(false).to.not.be.ok;

// typeof
expect('test').to.be.a('string');
expect({ foo: 'bar' }).to.be.an('object');
expect(foo).to.be.an.instanceof(Foo);

// include
expect([1, 2, 3]).to.include(2);
expect('foobar').to.contain('foo');
expect({ foo: 'bar', hello: 'universe' }).to.include.keys('foo');

// empty
expect([]).to.be.empty;
expect('').to.be.empty;
expect({}).to.be.empty;

// match
expect('foobar').to.match(/^foo/);

基本上，expect 斷言的寫法都是一樣的。頭部是 expect 方法，尾部是斷言方法，比如 equal、a/an、ok、match 等。兩者之間使用 to 或 to.be 連接。如果 expect 斷言不成立，就會(huì)拋出一個(gè)錯(cuò)誤。事實(shí)上，只要不拋出錯(cuò)誤，測(cè)試用例就算通過。

it('1 加 1 應(yīng)該等于 2', function() {});

上面的這個(gè)測(cè)試用例，內(nèi)部沒有任何代碼，由于沒有拋出了錯(cuò)誤，所以還是會(huì)通過。

Karma

基于 karma 測(cè)試常用的一些模塊

模塊安裝

# 基礎(chǔ)測(cè)試庫(kù)
npm install karma-cli -g
npm install karma mocha karma-mocha --save-dev

# 斷言庫(kù)
npm install should --save-dev
npm install karma-chai --save-dev

# 瀏覽器相關(guān)
npm install karma-firefox-launcher --save-dev
npm install karma-chrome-launcher --save-dev

如果對(duì)軟件測(cè)試、接口測(cè)試、自動(dòng)化測(cè)試、面試經(jīng)驗(yàn)交流。感興趣可以加軟件測(cè)試交流：1085991341，還會(huì)有同行一起技術(shù)交流。

配置

這里的配置主要關(guān)注的是karma.conf.js的相關(guān)配置。如果要使用 karma 和 mocha 最好通過npm install karma-cli -g全局安裝karma-cli。

需要注意的兩個(gè)字段:

  • singleRun: 如果值為 true, 則在瀏覽器運(yùn)行完測(cè)試后會(huì)自動(dòng)退出關(guān)閉瀏覽器窗口。singleRun的值我們可以更具運(yùn)行環(huán)境來動(dòng)態(tài)賦值, 可以啟動(dòng)命令中添加NODE_ENV變量。
  • browsers: 瀏覽器配置(可以配置多個(gè)瀏覽器); 如果瀏覽器無法啟動(dòng)需要進(jìn)行相關(guān)瀏覽器的配置。設(shè)置自啟動(dòng)瀏覽器時(shí)候如果瀏覽器啟動(dòng)失敗可能需要設(shè)置為--no-sandbox模式。
{
  "browsers": ["Chrome", "ChromeHeadless", "ChromeHeadlessNoSandbox"],
  "customLaunchers": {
    "ChromeHeadlessNoSandbox": {
      "base": "ChromeHeadless",
      "flags": ["--no-sandbox"]
    }
  }
}

或者

{
  "browsers": ["Chrome_travis_ci"],
  "customLaunchers": {
    "Chrome_travis_ci": {
      "base": "Chrome",
      "flags": ["--no-sandbox"]
    }
  }
}

Github項(xiàng)目接入Travis.CI進(jìn)行集成自動(dòng)化測(cè)試的步驟

  • 在github創(chuàng)建并完成一個(gè)可以待測(cè)試的項(xiàng)目。這里的完成是指需要完成基本的項(xiàng)目功能，和測(cè)試用例代碼。
  • 配置travis-ci能識(shí)別讀取的配置文件，這樣travis-ci接入的時(shí)候才能夠知道測(cè)試時(shí)的一些配置。
  • github 和 travis-ci 是個(gè)站點(diǎn)，換句話說就是兩個(gè)東西如果能打通呢。需要用戶登錄 travis-ci 并授權(quán)訪問到你的 github 項(xiàng)目并進(jìn)行相關(guān)的項(xiàng)目設(shè)置。
  • 接入完成后就可以根據(jù)自己的需要來運(yùn)行寫好的測(cè)試代碼，也可以設(shè)置定期任務(wù)去跑測(cè)試。

項(xiàng)目創(chuàng)建、完善項(xiàng)目功能和測(cè)試代碼。

  • 項(xiàng)目需求： 實(shí)現(xiàn)一個(gè)求和方法
  • 測(cè)試: 通過 mocha 來測(cè)試完成的求和方法。

下面是項(xiàng)目結(jié)構(gòu)，項(xiàng)目創(chuàng)建完成后通過 npm i mocha -D 安裝 mocha 模塊。然后在本地運(yùn)行 npm test 看是否能夠測(cè)試通過。如果能夠測(cè)試通過則說明我們的可以繼續(xù)下一步了。

創(chuàng)建 travis-ci 測(cè)試配置文件

創(chuàng)建 travis-ci 配置文件 .travis.yml, 文件內(nèi)容。更多關(guān)于配置文件的說明在travis官網(wǎng)可查詢

language: node_js
node_js:
  - "node"
  - "8.9.4"

至此基本完成了項(xiàng)目開發(fā)和測(cè)試代碼編寫的過程，下一步就可以接入 travis-ci 測(cè)試了。

接入 travis-ci

通過GitHub登錄 travis-ci 的官網(wǎng)

找到GitHub上剛才創(chuàng)建的需要測(cè)試的項(xiàng)目，并開啟測(cè)試

查看測(cè)試過程，及時(shí)發(fā)現(xiàn)問題。

查看測(cè)試狀態(tài)是否通過測(cè)試，如果未通過及時(shí)排查問題反復(fù)修改；如果通過可以在項(xiàng)目文檔中添加一個(gè)測(cè)試通過的標(biāo)識(shí)。


以上內(nèi)容就是本篇的全部?jī)?nèi)容以上內(nèi)容希望對(duì)你有幫助，有被幫助到的朋友歡迎點(diǎn)贊，評(píng)論。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

友情鏈接更多精彩內(nèi)容