前端測試框架 Jest

美團點評點餐發表於2019-03-04
前端框架

作者介紹：林列歡，美團點評點餐團隊成員。

前端測試工具一覽

前端測試工具也和前端的框架一樣紛繁複雜，其中常見的測試工具，大致可分為測試框架、斷言庫、測試覆蓋率工具等幾類。在正式開始本文之前，我們先來大致瞭解下它們：

測試框架

測試框架的作用是提供一些方便的語法來描述測試用例，以及對用例進行分組。

測試框架可分為兩種： TDD （測試驅動開發）和 BDD （行為驅動開發），我理解兩者間的區別主要是一些語法上的不同，其中 BDD 提供了提供了可讀性更好的用例語法，至於詳細的區別可參見 The Difference Between TDD and BDD 一文。

常見的測試框架有 Jasmine, Mocha 以及本文要介紹的 Jest 。

斷言庫

斷言庫主要提供語義化方法，用於對參與測試的值做各種各樣的判斷。這些語義化方法會返回測試的結果，要麼成功、要麼失敗。常見的斷言庫有 Should.js, Chai.js 等。

測試覆蓋率工具

用於統計測試用例對程式碼的測試情況，生成相應的報表，比如 istanbul 。

Jest

為什麼選擇 Jest

Jest 是 Facebook 出品的一個測試框架，相對其他測試框架，其一大特點就是就是內建了常用的測試工具，比如自帶斷言、測試覆蓋率工具，實現了開箱即用。

而作為一個面向前端的測試框架， Jest 可以利用其特有的快照測試功能，通過比對 UI 程式碼生成的快照檔案，實現對 React 等常見框架的自動測試。

此外， Jest 的測試用例是並行執行的，而且只執行發生改變的檔案所對應的測試，提升了測試速度。目前在 Github 上其 star 數已經破萬；而除了 Facebook 外，業內其他公司也開始從其它測試框架轉向 Jest ，比如 Airbnb 的嘗試 ，相信未來 Jest 的發展趨勢仍會比較迅猛。

安裝

Jest 可以通過 npm 或 yarn 進行安裝。以 npm 為例，既可用npm install -g jest進行全域性安裝；也可以只區域性安裝、並在 package.json 中指定 test 指令碼：

{
  "scripts": {
    "test": "jest"
  }
}
複製程式碼

Jest 的測試指令碼名形如*.test.js，不論 Jest 是全域性執行還是通過npm test執行，它都會執行當前目錄下所有的*.test.js 或 *.spec.js 檔案、完成測試。

基本使用

用例的表示

表示測試用例是一個測試框架提供的最基本的 API ， Jest 內部使用了 Jasmine 2 來進行測試，故其用例語法與 Jasmine 相同。test()函式來描述一個測試用例，舉個簡單的例子：

// hello.js
module.exports = () => `Hello world`
複製程式碼
// hello.test.js
let hello = require(`hello.js`)

test(`should get "Hello world"`, () => {
    expect(hello()).toBe(`Hello world`) // 測試成功
    // expect(hello()).toBe(`Hello`) // 測試失敗
})
複製程式碼

其中toBe(`Hello world`)便是一句斷言（ Jest 管它叫 “matcher” ，想了解更多 matcher 請參考文件）。寫完了用例，執行在專案目錄下執行npm test，即可看到測試結果：

若測試失敗，會標識出失敗的斷言位置，結果如下：

用例的預處理或後處理

有時我們想在測試開始之前進行下環境的檢查、或者在測試結束之後作一些清理操作，這就需要對用例進行預處理或後處理。對測試檔案中所有的用例進行統一的預處理，可以使用 beforeAll() 函式；而如果想在每個用例開始前進行都預處理，則可使用 beforeEach() 函式。至於後處理，也有對應的 afterAll() 和 afterEach() 函式。

如果只是想對某幾個用例進行同樣的預處理或後處理，可以將先將這幾個用例歸為一組。使用 describe() 函式即可表示一組用例，再將上面提到的四個處理函式置於 describe() 的處理回撥內，就實現了對一組用例的預處理或後處理：

describe(`test testObject`, () => {
    beforeAll(() => {
        // 預處理操作
    })

    test(`is foo`, () => {
       expect(testObject.foo).toBeTruthy()
    })

    test(`is not bar`, () => {
        expect(testObject.bar).toBeFalsy()
    })

    afterAll(() => {
        // 後處理操作
    })
})
複製程式碼

測試非同步程式碼

非同步程式碼的測試，關鍵點在於告知測試框架測試何時完成，讓其在恰當的時機進行斷言。針對幾種常見的非同步程式碼形式， Jest 也提供了相應的非同步測試語法。首先對於非同步回撥，向其傳入並執行 done 函式， Jest 會等 done 回撥執行結束後，結束測試：

// asyncHello.js
module.exports = (name, cb) => setTimeout(() => cb(`Hello ${name}`), 1000)
複製程式碼
// asyncHello.test.js
let asyncHello = require(`asyncHello.js`)

test(`should get "Hello world"`, (done) => {
    asyncHello(`world`, (result) => {
        expect(result).toBe(`Hello world`)
        done()
    })
})
複製程式碼

此外，對於 Promise 控制的非同步程式碼，可以直接在 then 回撥中進行斷言，只要保證在用例中返回該 Promise 物件即可：

// promiseHello.js
module.exports = (name) => {
    return new Promise((resolve) => {
        setTimeout(() => resolve(`Hello ${name}`), 1000)
    })
}
複製程式碼
// promiseHello.test.js
let promiseHello = require(`promiseHello.js`)

it(`should get "Hello world"`, () => {
    expect.assertions(1); // 確保至少有一個斷言被呼叫，否則測試失敗
    return promiseHello(`world`).then((data) => {
        expect(data).toBe(`Hello world`)
    })
})
複製程式碼

Jest 也支援 async/await 語法的測試，無需多餘的操作，只要在 await 後進行斷言即可，和同步測試的寫法一致。

測試覆蓋率

Jest 內建了測試覆蓋率工具istanbul，要開啟，可以直接在命令中新增 --coverage 引數，或者在 package.json 檔案進行更詳細的配置。

執行 istanbul 除了會再終端展示測試覆蓋率情況，還會在專案下生產一個 coverage 目錄，內附一個測試覆蓋率的報告，讓我們可以清晰看到分支的程式碼的測試情況。比如下面這個例子：

// branches.js
module.exports = (name) => {
    if (name === `Levon`) {
        return `Hello Levon`
    } else {
        return `Hello ${name}`
    }
}
複製程式碼
// branches.test.js
let branches = require(`../branches.js`)

describe(`Multiple branches test`, ()=> {
    test(`should get Hello Levon`, ()=> {
          expect(branches(`Levon`)).toBe(`Hello Levon`)
    });
    // test(`should get Hello World`, ()=> {
    //       expect(branches(`World`)).toBe(`Hello World`)
    // });  
})
複製程式碼

執行 jest --coverage 可看到產生的報告裡展示了程式碼的覆蓋率和未測試的行數：

如果我們把branches.test.js中的註釋去掉，跑遍測試物件中的所有分支，測試覆蓋率就是100%了：

在前端專案中使用

搭配React和其它框架

針對前端框架的測試， Jest 的一大特色就是提供了快照測試功能。首次執行快照測試，會讓 UI 框架生產一個可讀的快照，再次測試時便會通過比對快照檔案和新 UI 框架產生的快照判斷測試是否通過。對於 React ，我們可以通過下面的方法生產一個快照：

import React from `react`;
import Link from `../Link.react`;
import renderer from `react-test-renderer`;

it(`renders correctly`, () => {
    const tree = renderer.create(
        <Link page="http://www.facebook.com">Facebook</Link>
    ).toJSON();
    expect(tree).toMatchSnapshot();
});
複製程式碼

執行測試，我們可以看到生成一個快照檔案如下：

exports[`renders correctly 1`] = `
<a
    className="normal"
    href="http://www.facebook.com"
    onMouseEnter={[Function]}
    onMouseLeave={[Function]}
>
    Facebook
</a>
`;
複製程式碼

這個可讀的快照檔案以可讀的形式展示了 React 渲染出的 DOM 結構。相比於肉眼觀察效果的 UI 測試，快照測試直接由Jest進行比對、速度更快；而且由於直接展示了 DOM 結構，也能讓我們在檢查快照的時候，快速、準確地發現問題。

除了 React ，Jest 文件中也提供了針對其他框架進行測試的指南。

無縫遷移

如果你的專案中已經使用了別的測試框架，比如 Mocha，有一個第三方工具jest-codemods可以自動把用例遷移成 Jest 的用例，降低了遷移成本。

後記：前端自動化測試，值不值得？

近幾年前端工程化的發展風起雲湧，但是前端自動化測試這塊內容大家卻似乎不太重視。雖然專案迭代過程中會有專門的測試人員進行測試，但等他們來進行測試時，程式碼已經開發完成的狀態。與之相比，如果我們在開發過程中就進行了測試（直接採用 TDD 開發模式、或者針對既有的模組寫用例），會有如下的好處：

  • 保障程式碼質量和功能的實現的完整度
  • 提升開發效率，在開發過程中進行測試能讓我們提前發現 bug ，此時進行問題定位和修復的速度自然比開發完再被叫去修 bug 要快許多
  • 便於專案維護，後續任何程式碼更新也必須跑通測試用例，即使進行重構或開發人員發生變化也能保障預期功能的實現

當然，凡事都有兩面性，好處雖然明顯，卻並不是所有的專案都值得引入測試框架，畢竟維護測試用例也是需要成本的。對於一些需求頻繁變更、複用性較低的內容，比如活動頁面，讓開發專門抽出人力來寫測試用例確實得不償失。

而那些適合引入測試場景大概有這麼幾個：

  • 需要長期維護的專案。它們需要測試來保障程式碼可維護性、功能的穩定性
  • 較為穩定的專案、或專案中較為穩定的部分。給它們寫測試用例，維護成本低
  • 被多次複用的部分，比如一些通用元件和庫函式。因為多處複用，更要保障質量

以上就是我對前端測試的一點淺見，歡迎斧正。

Ref

聊一聊前端自動化測試

相關文章