天天看點

前端自動化測試 —— Jest 測試架構應用

作者:閃念基因

什麼是自動化測試

在軟體測試中,自動化測試指的是使用獨立于待測軟體的其他軟體來自動執行測試、比較實際結果與預期并生成測試報告這一過程。在測試流程已經确定後,測試自動化可以自動執行的一些重複但必要的測試工作。也可以完成手動測試幾乎不可能完成的測試。對于持續傳遞和持續內建的開發方式而言,測試自動化是至關重要的。 ——來自 WiKi 百科

為什麼要用前端自動化測試

随着前端項目的發展,其規模和功能日益增加。為了提高項目的穩定性和可靠性,除了需要測試工程師外,前端自動化測試也成為了不可或缺的一環。采用前端自動化測試可以有效地提高代碼品質,降低出錯的機率,進而使項目更加健壯和更易維護。

前端自動化分類和思想

單元測試

又稱為子產品測試 ,是針對程式子產品(軟體設計的最小機關)來進行正确性檢驗的測試工作。在前端中,一個函數、一個類、一個子產品檔案,都可以進行單元測試,測試時每個子產品都是互不幹擾的。

前端自動化測試 —— Jest 測試架構應用

內建測試

是在單元測試的基礎上,測試再将所有的軟體單元按照概要設計規格說明的要求組裝成子產品、子系統或系統的過程中各部分工作是否達到或實作相應技術名額及要求的活動。使用者的開始操作到結束操作這一整個行為流程可以當作內建測試。

前端自動化測試 —— Jest 測試架構應用

TDD 測試驅動開發(Test Driven Development)

開發流程:

前端自動化測試 —— Jest 測試架構應用

TDD 是趨向于白盒測試,需要開發者對目前編寫的子產品思路足夠清晰。

優勢:

  1. 長期減少回歸 bug。
  2. 代碼品質更好,可維護性高。
  3. 測試覆寫率高(先寫測試用例,再實作功能)。
  4. 錯誤測試代碼不容易出現(測試在開發之前執行)。

BDD 行為驅動開發(Behavior Driven Development)

開發流程:

前端自動化測試 —— Jest 測試架構應用

BDD 趨向于黑盒測試,隻關注使用者的一整套行為流程下來是否會成功。

優勢:

  1. 對于使用者行為的整個流程把控程度較高,對于開發人員來說這樣安全感高。

如何自己寫非架構測試用例

不使用測試架構,我們該如何測試自己的子產品呢?如果我們想要測試下面的代碼,應該需要兩個值,一個是 期望值 ,另一個是函數執行的 結果值 ,我們需要對比兩個值來進行判斷目前函數是否通過了測試用例。

// index.js
function ZcyZooTeam(str) {
  return 'Zcy' + str;
}
           

需要下面的 if / else 進行判斷目前的期望值 value 和結果值 result 是否相等,如果相等說明我們的測試用例通過了。我們将這兩段代碼複制到浏覽器中,下面的執行不會通過,并會抛出錯誤,隻有我們将傳入值改為 ZooTeam 才會成功執行。

// no-jest.js
const result = ZcyZooTeam('Zero');
const value = 'ZooTeam';
if(result !== value) {
  throw Error(`ZcyZooTeam 結果應為${value}, 但實際結果為${result}`);
}
           
前端自動化測試 —— Jest 測試架構應用

是否能簡化?

如果我們有多個函數需要測試,你應該不想寫許多個 if / else 代碼塊吧?是以我們要将上面的代碼塊進行優化成一個函數。

// no-jest.js
function expect(result) {
  return {
    // 用于判斷是否為期望值
    toBe(value) {
      if(result !== value) {
        throw Error(`結果應為${value}, 但實際結果為${result}`);
      }
      console.log('測試通過!');
    }
  }
}

// 執行測試
expect(ZcyZooTeam('Zero')).toBe('ZcyZooTeam');
           

經過上面的封裝,我們就可以隻寫一行代碼進行測試了!

如何能清晰地看到我測的是哪個呢?

雖然上面的封裝隻需要書寫一行代碼就可以測試了,但是我們不知道執行結果和測試用例之間的對應關系,我們需要輸出的文字來告訴我們目前是哪個測試用例執行了。

// no-jest.js
// 再封裝如下方法
function test(msg, fn) {
  try {
    fn();
    console.log(msg + '測試通過!');
  } catch (error) {
    console.log(msg + '測試未通過!' + error);
  }
}

test('測試ZcyZooTeam', () => {
  expect(ZcyZooTeam('Zero')).toBe('ZcyZooTeam')
})
           

成功和失敗都會進行提示,這樣我們就可以知道目前是哪個測試用例成功/失敗了。

Jest的書寫方式也是同上,如果上面的一整套代碼了解了的話,你已經可以寫Jest的測試腳本了,下面将進入Jest的配置。

如何使用 Jest 測試架構進行自動化測試?

主流的前端自動化測試架構

Jasmine

Jasmine 優點:易于學習和使用,支援異步測試,可以在浏覽器和 Node.js 環境中運作,可以生成易于閱讀的測試報告,可以與其他庫和架構內建。

MOCHA

MOCHA 優點:支援異步測試和 Promise ,可以在浏覽器和 Node.js 環境中運作,可以與其他庫和架構內建,可以生成易于閱讀的測試報告,可以使用各種插件和擴充來增強其功能。

Jest

Jest 是針對子產品進行測試,單元測試對單個子產品進行測試,內建測試對多個子產品進行測試。

Jest 優點:速度快(單子產品測試時,執行過的子產品不會重複執行),API簡單,易配置,隔離性好(執行環境相對隔離,每個檔案單獨隔離互不幹擾),監控模式(更靈活的運作各種測試用例),适配編輯器多,Snapshot(快照),多項目運作(背景前台測試用例并行測試),生成可視化覆寫率簡單,Mock 豐富。

準備工作 —— Jest 的配置

npm i jest --save-D

// 初始化 jest 的配置檔案
npx jest --init

// 你将在那個環境進行測試,回車即可選擇
// 第一個是 node 環境、第二個是浏覽器環境
? Choose the test environment that will be used for testing › - Use arrow-keys. Return to submit.
    node
❯   jsdom (browser-like)

// 是否需要 jest 生成測試覆寫率報告
? Do you want Jest to add coverage reports? › (y/N)

// 是否需要在測試結束後清除模拟調用
? Automatically clear mock calls and instances between every test? › (y/N)

// 建立 jest.config.js 檔案
  Configuration file created at /Users/zcy1/Desktop/demo/auto-test-jest-demo/jest.config.js
           

以上方法執行結束後,會生成一個 jest.config.js 檔案,裡面包含了 Jest 的配置項,每個配置項都會帶有描述,在初始化的兩個配置也會展現在配置檔案中

使用 babel 轉換來使用 ES6 形式的導入和導出

// .babelrc
// 如果想用 es6 的形式導出,需要使用 babel 插件進行轉換
// @babel/core  @babel/preset-env

// 建立 .babelrc 檔案
// 為了在 node 環境下使用 es6 的導出,需要使用 babel 進行轉換
{
  // 設定插件集合
  "presets": [
    // 使用目前插件,可以進行轉換
    // 數組的第二項為插件的配置項
    [
      "@babel/preset-env", {
        // 根據 node 的版本号來結合插件對代碼進行轉換
        "targets": {
          "node": "current"
        }
      }
    ]
  ]
}
           

配置好後需要将 package.json 中的 test 指令的 value 改為 jest --watchAll ,代表監聽所有有修改的測試檔案,然後控制台執行 npm run test 就可以執行測試用例了。

Jest 啟動時會進行如下流程

  1. npm run test
  2. jest (babel-jest) 檢測目前環境是否安裝了 babel
  3. 如果安裝了則會去 babelrc 中取配置
  4. 取到後執行代碼轉換
  5. 最後再執行轉化過的測試用例代碼

如何生成一個測試用例覆寫率報告?

經過上面的 Jest 配置,我們就可以通過下面的 npx 指令來生成測試覆寫率報告了

npx jest --coverage
           

會生成一個名為 coverage 的檔案夾,打開裡面的 html 就可以看到你的覆寫率,其中 Statements 是語句覆寫率(每個語句是否執行),Branches 是分支覆寫率(每個 if 塊是否執行),Functions是函數覆寫率(每個函數是否執行),Lines 是行覆寫率(每行是否執行),通過修改 coverageDirectory 的值可以改變測試覆寫率生成檔案夾的名字

Jest 基礎比對器

上面我們說過了,Jest 的用法和我們封裝的那幾個函數是一樣的,都是執行 test 函數并向函數中傳遞參數,第一個參數是你目前測試用例的描述,第二個參數是需要執行的比對規則。

比對器

toBe

toBe 比對器,期待是否與比對器中的值相等 相當于 object.is ===

// jest.test.js
test("測試", () => {
  expect(1).toBe(1);  // 通過
  const a = { name: 'Zero' };
  // 因為 a 的引用位址,和 toBe 中對象的引用位址不一緻,會導緻測試不通過,需要使用其他的比對器
  expect(a).toBe({ name: 'Zero' });  // 失敗
});
           

toEqual

toEqual 比對器,隻會比對對象中的内容是否相等。

// jest.test.js
test('測試對象相等', () => {
  const a = { name: 'Zero' };
  expect(a).toEqual({ name: 'Zero' });  // 斷言
})
           

toBeNull

toBeNull 比對器,可以判斷變量是否為 null ,隻能比對 null。

// jest.test.js
test('測試是否為null', () => {
  const a = null;
  expect(a).toBeNull();
})
           

toBeUndefined

toBeUndefined 比對器,可以判斷變量是否為 undefined ,隻能比對 undefined。

// jest.test.js
test('測試是否為undefined', () => {
  const a = undefined;
  expect(a).toBeUndefined();
})
           

toBeDefined

toBeDefined 比對器,希望被測試的值是定義好的。

// jest.test.js
test('測試變量是否定義過', () => {
  const a = '';
  expect(a).toBeDefined();
})
           

toBeTruthy

toBeTruthy 比對器,可以判斷變量是否為真值,會對非 bool 值進行轉換。

// jest.test.js
test('測試變量真值', () => {
  const a = '123';
  expect(a).toBeTruthy();
})
           

toBeFalsy

toBeFalsy 比對器,可以判斷變量是否為假值,會對非 bool 值進行轉換。

// jest.test.js
test('測試變量假值', () => {
  const a = '';
  expect(a).toBeFalsy();
})
           

not修飾符

not 比對器,可以将比對後的結果進行取反。

// jest.test.js
test('測試變量不是假值', () => {
  const a = '1';
  expect(a).not.toBeFalsy();
})
           

toBeGreaterThan

toBeGreaterThan 比對器,期望值是否大于比對器的參數。

// jest.test.js
test('是否大于 a 的數字', () => {
  const a = 123;
  expect(a).toBeGreaterThan(1);
})
           

toBeLessThan

toBeLessThan 比對器,期望值是否小于比對器的參數。

// jest.test.js
test('是否小于 a 的數字', () => {
  const a = 0;
  expect(a).toBeLessThan(1);
})
           

toBeGreaterThanOrEqual

toBeGreaterThanOrEqual 比對器,期望值是否大于或等于比對器的參數。

// jest.test.js
test('是否大于等于 a 的數字', () => {
  // toBeLessOrEqual 比對器,與之相反
  const a = 123;
  expect(a).toBeGreaterThanOrEqual(1);
})
           

toBeCloseTo

js 中,浮點數值在相加時不準确,使用 toBeCloseTo 比對器解決,趨近于 0.3。

// jest.test.js
test('是否大于等于 a 的數字', () => {
  const a1 = 0.1;
  const a2 = 0.2;
  expect(a1 + a2).toBeCloseTo(0.3);
})
           

toMatch

toMatch 比對器,比對目前字元串中是否含有這個值,支援正則。

// jest.test.js
test('是否包含 day ', () => {
  const a = 'happy every day';
  expect(a).toMatch('day');
})
           

toContain

toContain 比對器,判斷目前數組中是否包含這個元素,Set 也可以使用。

// jest.test.js
test('數組中是否包含 zoo 這個元素', () => {
  const a = ['zoo', 'ZooTeam', 'Zero'];
  expect(a).toContain('zoo');
})
           

toThrow

toThrow 比對器,可以捕捉抛出的異常,參數為抛出的 error ,可以用來判斷是否為某個異常。

// jest.test.js
const error = () => {
  throw new Error('error');
}
test('是否存在異常', () => {
  expect(error).toThrow();
})
           

以上就是 Jest 中比較基礎的比對器,可以結合 初始化 + 配置 + 基礎比對器 進行書寫測試用例。

指令行操作

在運作 npm run test 指令的時候,控制台執行測試用例成功或失敗後都會像下面的圖檔一樣出現幾行提示,讓你按對應的鍵進行操作。

前端自動化測試 —— Jest 測試架構應用

上面幾個指令行的意思如下:

1.f隻會跑測試未通過的用例,再次點選 f 會取消目前模式。

我們使用一個失敗的測試用例做一下示範

前端自動化測試 —— Jest 測試架構應用
前端自動化測試 —— Jest 測試架構應用

按下f後,Jest隻會執行剛才失敗的測試用例

前端自動化測試 —— Jest 測試架構應用

2.o隻監聽已改變的檔案,如果存在多個測試檔案,可以開啟,會與目前 git 倉庫中的送出進行比較,需要使用 git 來監聽哪個檔案修改了,也可以将 --watchAll 改為 --watch 隻會運作修改的檔案。

3. 根據測試用例檔案的正規表達式,過濾需要執行的測試用例檔案,No tests found, exiting with code 0如果填寫不對會進行提示,并不會跑任何測試用例。

4. 根據測試用例描述的正規表達式,過濾需要執行的測試用例。

5. 退出測試用例監聽。

異步測試

在正常的業務開發中,項目中不隻有同步代碼,還會有請求接口的異步代碼,異步代碼的測試與同步代碼有稍許不同,我們來看一下。

編寫一個接口請求

// getData.js
export const getData = (fn) => {
  axios.get('/getData').then((res) => {
    fn(res.data);
  })
}
           

對異步請求進行測試

// jest.test.js
// 異步調用回調函數需要添加 done 參數,是一個函數
test('getData 傳回結果為 { success: true }', (done) => {
  // 此處代碼無效,因為測試用例不會等待請求結束後的回調,測試用例執行完就直接結束了
  // getData1((data) => {
  //   expect(data).toEqual({
  //     success: true
  //   })
  // })
  
  getData1((data) => {
    expect(data).toEqual({
      success: true
    })
    // 需要在結束前調用 done 函數, Jest 會知道到 done 才會結束,才可以正确測試異步函數
    done();
  })
})
           

需要注意的是,如果傳入了形參 done,但是沒有使用,這個測試用例就會處于一直執行的狀态,直到執行逾時。

前端自動化測試 —— Jest 測試架構應用

還可以結合promise進行使用

// getData.js
export const getData2 = () => {
  return axios.get('http://www.dell-lee.com/react/api/demo.json')
}

// jest.test.js
test('getData 傳回結果為 { success: true }', () => {
  // 使用 promise 時需要 return,在 then 中使用 done 也可以
  return getData2().then(res => {
    expect(res.data).toEqual({
      success: true
    })
  })
})

// 測試請求是否 404
test('getData 傳回結果為 404', () => {
  // 由于不觸發 catch 就不會走測試校驗,是以會成功,我們需要做一下限制
  // 這行代碼限制下面的代碼中必須要執行一次 expect 方法,如果非 404 就不會走下面的 expect,則測試不會通過
  expect.assertions(1);
  // 使用 promise 時需要 return
  // 如果隻想測試 404 這樣寫是有問題的,需要配合 assertions 使用
  return getData2().catch(err => {
    expect(err.toString().indexOf('404') > -1).toBe(true)
  })
})

// 另一種寫法
test('getData 傳回結果為 { success: true }', () => {
  // 會傳回很多資料,其中包含 data 對象
  // getData2().then((res) => console.log(res))
  // {
  //   status: 200,
  //   statusText: 'OK',
  //   headers: {},
  //   ......
  //   data: { success: true }
  // }
  // resolves 方法會将接口傳回的字段全部擷取,再使用 toMatchObject 方法進行比對大對象中是否存在 data 對象
  return expect(getData2()).resolves.toMatchObject({
    data: {
      success: true
    }
  })
})

// 還可以使用 async/await
test('getData 傳回結果為 { success: true }', async () => {
  await expect(getData2()).resolves.toMatchObject({
    data: {
      success: true
    }
  })
})
           

鈎子函數

鈎子函數可以當作一個測試用例的生命周期來看待,有 beforeAll 、beforeEach 、afterEach 、afterAll 。

以下是一些關于鈎子函數的概念和場景:

beforeAll:在所有測試用例執行前運作

beforeEach:在每個測試用例執行前執行一次

afterEach:在每個測試用例執行後執行一次

afterAll:在所有測試用例結束後運作

有時候,需要測試一個類中的多個方法,這些方法可能會反複操作同一個對象上的屬性。如果使用同一個執行個體,就會互相幹擾,導緻測試用例無法通過。此時,需要使用不同的執行個體來進行測試。

Counter 類

// Counter.js
class Counter {
  constructor() {
    this.number = 0;
  }

  add() {
    this.number += 1;
  }

  minus() {
    this.number -= 1;
  }
}

export default Counter;
           

我們想要測試裡面的 add 和 minus 方法是否正确,需要執行個體化一個對象進行測試。但是下面的測試用例使用的永遠都是同一個執行個體,第二個測試用例永遠都不會通過。因為執行了第一個測試用例,第二個測試用例的值隻能是 0。

// jest.test.js
const count = new Counter();
// 使用下方兩種測試方法會互相影響,先加一後減一,結果永遠是 0
test('測試加法', () => {
  count.add();
  expect(count.number).toBe(1);
})

test('測試減法', () => {
  count.minus();
  expect(count.number).toBe(-1);
})
           

需要使用鈎子函數,在每次執行測試用例的時候,都讓他重新執行個體化一個對象

// jest.test.js
let count = null;
// 類似于生命周期
// 會在測試用例執行前運作
beforeAll(() => {
  console.log('beforeAll')
});

// 會在每個測試用例執行前執行一次,這樣就會解決上面互相影響的問題
beforeEach(() => {
  console.log('beforeEach')
  count = new Counter();
});

// 會在每個測試用例執行後執行一次
afterEach(() => {
  console.log('afterEach')
});

// 會在所有測試用例結束後運作
afterAll(() => {
  console.log('afterAll');
});

test('測試加法', () => {
  console.log('add')
  count.add();
  expect(count.number).toBe(1);
})

test('測試減法', () => {
  console.log('minus')
  count.minus();
  expect(count.number).toBe(-1);
})
           

分組方法 discribe

// jest.test.js
let count = null;
// describe 方法,可以将測試用例進行分組,更加好維護同類型功能的測試用例
describe('count 測試', () => {
  beforeAll(() => {
    console.log('beforeAll')
  });
  beforeEach(() => {
    console.log('beforeEach')
    count = new Counter();
  });
  afterEach(() => {
    console.log('afterEach')
  });
  afterAll(() => {
    console.log('afterAll');
  });
  
  // 将 add 類型進行分組
  describe('測試 add 類型用例', () => {
    // 在 describe 方法中,鈎子函數會按照層級嵌套進行執行,先執行外部,再執行内部,不同的 describe 互不幹擾
    beforeEach(() => {
      console.log('beforeEach add');
    });
    test('測試加法', () => {
      console.log('add')
      count.add();
      expect(count.number).toBe(1);
    })
  })

  // 将 minus 類型進行分組
  describe('測試 minus 類型用例', () => {
    test('測試減法', () => {
      console.log('minus')
      count.minus();
      expect(count.number).toBe(-1);
    })
  })
})
           

加上 describe 方法的執行效果如下圖。

前端自動化測試 —— Jest 測試架構應用

Mock

在日常開發中,目前端開發差不多後,後端接口可能還沒有提供,這個時候我們就要用 Mock 資料。而 Jest 也有 Mock 方法,用于模拟一些 JavaScript 的函數等。

我們先來一個比較簡單的mock.fn

// mock.js
export const runFn = (fn) => {
  fn(123);
}

// mock.test.js
test('測試 runFn', () => {
  // 通過 jest 的 fn 方法建立一個模拟函數,如果不傳參數會預設生成一個函數
  // 1. 通過 func.mock 擷取想要的值
  // 2. 可以自定義傳回值
  // 3. 改變内部函數的實作,模拟接口請求,不請求代碼中的接口
  const func = jest.fn( () => 456 );

  // 還可以使用 mockReturnValueOnce 方法進行控制輸出,兩種方法都使用時會覆寫 fn 方法中的傳回值,支援鍊式調用
  // 将 Once 去掉與 fn 方法一樣,多次會傳回相同的值
  func.mockReturnValueOnce('zoo')

  // 傳回 this 方法 mockReturnThis
  func.mockReturnThis();

  // 還可以使用 mockImplementation 方法書寫函數内部,可以在函數内部寫邏輯,與 jest.fn 方法的參數一樣,還可以填加 Once
  func.mockImplementation(() => {
    return '123';
  })

  // 執行被測函數
  runFn(func);
  runFn(func);
  
  // console.log(func.mock)
  // 因為被調用了兩次,是以長度都是 2
  // {
  //   calls: [ [123], [123] ],  // 每次的調用情況,傳遞的參數是什麼
  //   instances: [ undefined, undefined ],  // 每次調用的 this 指向,被調用了幾次
  //   invocationCallOrder: [ 1, 2 ],  // 執行順序,可能會傳入同一個或多個方法中,需要記錄一下順序
  //   results: [  // mock 函數每次執行後的傳回值
  //     { type: 'return', value: 456 },
  //     { type: 'return', value: 456 }
  //   ]
  // }

  // 通過 toBeCalled 判斷函數是否被調用
  expect(func).toBeCalled();

  // 判斷目前函數調用了幾次 被調用了兩次
  expect(func.mock.calls.length).toBe(2);

  // 判斷參數是什麼
  expect(func.mock.calls[0]).toEqual([123]);

  // 判斷每次調用的時候參數是什麼
  expect(func).toBeCalledWith(123);

  // 判斷傳回值
  expect(func.mock.results[0].value).toBe('zoo');
})
           

Mock 高階用法

如果需要通過修改請求的方式進行測試,而不使用測試架構,我們可能需要修改請求的代碼邏輯。但是,Jest 提供了一種進階的 Mock 方法。我們隻需在項目根目錄下建立一個名為 __mocks__ 的檔案夾,然後在其中自定義檔案内容并導出,就可以使用自己定義的 Mock 函數而不必修改請求代碼邏輯。

前端自動化測試 —— Jest 測試架構應用
前端自動化測試 —— Jest 測試架構應用

書寫測試用例檔案,引入__mocks__檔案夾中的函數

// mocker.test.js
// 使用 mock 方法引用 __mocks__ 下建立的 mock.js
jest.mock("./mock");
// 執行完上面的方法,會直接尋找 __mocks__ 下的getData,而不是正常的請求檔案
// 由于 mock 中沒有 getCode 方法,最好隻 mock 異步函數,同步函數直接測試即可
// 可以不必須建立 __mocks__ 檔案夾
import {
  getData,
} from "./mock";

// 需要使用下面的 requireActual 方法來引用非 mock 檔案夾下的 getCode
const { getData } = jest.requireActual("./mock");

// 高階mock
// 此處直接使用 __mocks__ 目錄下的 mock 檔案中的函數
test("測試 getData", () => {
  return getData().then((data) => {
    expect(eval(data)).toEqual("123");
  });
});
           

Mock-timers

在特定的業務中,需要使用到定時器,測試的時候也是需要修改代碼來測試不同時間,最主要的一點是,我們需要等時間才能看到我們的執行結果,Jest 也有關于定時器的 Mock 函數。

// mock.js
export const timer = (fn) => {
  setTimeout(() => {
    fn();
    setTimeout(() => {
      fn();
    }, 3000)
  }, 3000)
}
           
// mock-timers.test.js
import { timer } from './mock';

// 使用 useFakeTimers 方法告知 Jest 在下面的測試用例,如果用到了定時器異步函數的時候,都是用假的 timers 進行模拟
jest.useFakeTimers();

test('測試 timer', () => {
  const fn = jest.fn();
  timer(fn);

  // 使用 runAllTimers 方法,讓定時器立即執行,和 useFakeTimers 配合使用
  jest.runAllTimers();

  // 如果代碼中有多個定時器嵌套,隻想測試最外層的定時器,則需要使用 runOnlyPendingTimers 方法
  // 這個方法會隻執行目前在隊列中的函數,可以多次調用
  jest.runOnlyPendingTimers();
  jest.runOnlyPendingTimers();

  // advanceTimersByTime 方法,可以快進時間
  // 因為 timer 中,三秒後隻執行了第一層,如果是六秒,則會執行兩次 fn
  jest.advanceTimersByTime(3000);
})
           

snapshot 快照

到這裡我們已經可以測試一些代碼了,但是我們要如何捕捉執行結果和目前做對比呢?這時候就要使用快照功能了。

// snapshot.js
export const config1 = () => {
  return {
    method: 'GET',
    url: '/api',
    time: new Date()
  }
}

export const config2 = () => {
  return {
    method: 'GET',
    url: '/api',
    time: new Date().getTime()
  }
}
           
// snapshot.test.js
import { config1, config2 } from "./snapshot";

test('測試 config1 傳回值', () => {
  // 但如果每次函數修改的時候,目前測試用例也要不斷地修改
  // expect(config()).toEqual({
  //   method: 'GET',
  //   url: '/api'
  // });

  // 需要使用快照比對 toMatchSnapshot 方法
  // 此方法會生成一個 __snapshots__ 目錄,下面的檔案中,第一次執行中 config 生成的結果會存到快照檔案中
  // 快照會根據 test 方法中的描述生成一個映射關系
  // 修改後的 config 的執行結果與快照中的結果不同時會報錯,需要更新快照
  // 如果 config 中有的值是每次運作都會變化的,那麼每次快照都不會與目前執行相同,除非執行後再更新快照
  // 需要将在 toMatchSnapshot 方法中傳遞一個參數,設定一下 time 為任意格式的 Date 類型
  expect(config1()).toMatchSnapshot({
    time: expect.any(Date)
  });
})

test('測試 config2 傳回值', () => {
  expect(config2()).toMatchSnapshot({
    time: expect.any(Number)
  });
})
           

行内快照生成

// snapshot.test.js
// 需要安裝 prettier
test("測試 config2 傳回值", () => {
  // toMatchInlineSnapshot 方法,将執行快照放到行内中,會放到 toMatchInlineSnapshot 方法中
  expect(config2()).toMatchInlineSnapshot(
    {
      time: expect.any(Number)
    },
    `
    Object {
      "method": "GET",
      "time": Any<Number>,
      "url": "/api",
    }
  `
  );
});

           

對 dom 節點測試

Jest 内部自己模拟了一套 jsDom ,可以在 node 的環境下執行需要浏覽器環境 dom 的測試用例。

// dom.js
import $ from 'jquery';
const addDiv = () => {
  // jQuery
  $('body').append('<div/>');
}

export default addDiv;

// dom.test.js
import addDiv from './dom';
import $ from 'jquery';

test('測試 addDiv', () => {
  addDiv();
  addDiv();
  console.log($('body').find('div').length);

  // 測試dom
  expect($('body').find('div').length).toBe(2);
  expect(document.getElementsByTagName('div').length).toBe(2);
})
           

VSCode 插件

Jest Snippets 用于快速生成 Jest 代碼塊的工具。

Jest 能夠檢測目前檔案夾中的測試用例并自動運作測試,還支援可視化操作,更新、執行以及單個執行等功能,非常友善!

常用配置解讀

module.exports = {
  // 檢測從哪個目錄開始,rootDir 代表根目錄
  roots: ["<rootDir>/src"],

  // 代碼測試覆寫率通過分析那些檔案生成的,!代表不要分析
  collectCoverageFrom: [
    // src 下所有 js jsx ts tsx 字尾的檔案
    "src/**/*.{js,jsx,ts,tsx}",

    // src 下所有 .d.ts 字尾的檔案
    "!src/**/*.d.ts"
  ],

  // 運作測試之前,我們額外需要準備什麼
  setupFiles: ["react-app-polyfill/jsdom"],

  // 當測試環境建立好後,需要做其他事情時可以引入對應的檔案
  setupFilesAfterEnv: ["<rootDir>/src/setupTests.js"],

  // 哪些檔案會被認為測試檔案
  testMatch: [
    // src 下的所有 __tests__ 檔案夾中的所有的 js jsx ts tsx 字尾的檔案都會被認為是測試檔案
    "<rootDir>/src/**/__tests__/**/*.{js,jsx,ts,tsx}",

    // scr 下的所有一 .test/spec.js/jsx/ts/tsx 字尾的檔案都會被認為是測試檔案
    "<rootDir>/src/**/*.{spec,test}.{js,jsx,ts,tsx}",
  ],

  // 測試運作的環境,會模拟 dom
  testEnvironment: "jsdom",

  // 測試檔案中引用一下字尾結尾的檔案會使用對應的處理方式
  transform: {
    // 如果引用的是 js jsx mjs cjs ts tsx 字尾的檔案會使用 /config/jest/babelTransform.js 檔案進行處理
    "^.+\\.(js|jsx|mjs|cjs|ts|tsx)#34;: "<rootDir>/config/jest/babelTransform.js",

    // 如果引用的是 css 字尾的檔案,會使用 /config/jest/cssTransform.js 檔案處理
    "^.+\\.css#34;: "<rootDir>/config/jest/cssTransform.js",

    // 不是以 js jsx mjs cjs ts tsx css json 這些為字尾的檔案會使用 /config/jest/fileTransform.js 檔案進行處理
    "^(?!.*\\.(js|jsx|mjs|cjs|ts|tsx|css|json)$)":
      "<rootDir>/config/jest/fileTransform.js",
  },

  // 忽略 transform 配置轉化的檔案
  transformIgnorePatterns: [
    // node_modules 目錄下的 js jsx mjs cjs ts tsx 字尾的檔案都不需要轉化
    "[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs|cjs|ts|tsx)#34;,

    // .module.css/sass/scss 字尾的檔案都不需要轉化
    "^.+\\.module\\.(css|sass|scss)#34;,
  ],

  // 自動化測試時,應用的子產品應該從哪裡尋找,預設是在 node_modules
  modulePaths: [],

  // 子產品名字使用哪種工具進行映射
  moduleNameMapper: {
    // 針對于 native 移動端
    // "^react-native#34;: "react-native-web",

    // 将 .module.css/sass/scss 子產品使用 identity-obj-proxy 工具進行轉化
    "^.+\\.module\\.(css|sass|scss)#34;: "identity-obj-proxy",
  },

  // 引入子產品時,進行自動查找子產品類型,逐個比對
  moduleFileExtensions: [
    "web.js",
    "js",
    "web.ts",
    "ts",
    "web.tsx",
    "tsx",
    "json",
    "web.jsx",
    "jsx",
    "node",
  ],

  // 監聽插件
  watchPlugins: [
    "jest-watch-typeahead/filename",
    "jest-watch-typeahead/testname",
  ],

  // 重置 mock
  resetMocks: true,
};
           

小結

在實際業務應用中,我們建議對可複用的元件、工具函數、工具類等一些無副作用,可預知結果的代碼來進行單元測試。在前期開發過程中的投入會大于沒有單元測試的投入,因為要寫一些測試用例,還要執行測試用例,優化代碼等。但是在長久疊代中,這種方法會比沒有進行單元測試的子產品更加穩定。

代碼位址

  1. 前置 demo :https://github.com/Jadony/Jest-demo
  2. Jest 簡單配置:https://github.com/Jadony/jest-config
  3. Jest 比對器:https://github.com/Jadony/jest-matchers
  4. 異步代碼測試:https://github.com/Jadony/jest-async
  5. Jest 鈎子函數:https://github.com/Jadony/jest-hook
  6. Jest 的 mock 函數:https://github.com/Jadony/jest-mock
  7. Jest 的快照:https://github.com/Jadony/jest-snapshot
  8. Jest 對 Dom 節點的測試:https://github.com/Jadony/jest-dom

參考文檔

  • 《前端要學的測試課 從Jest入門到TDD/BDD雙實戰》(https://coding.imooc.com/class/chapter/372.html#Anchor)

如果想學習更多内容,請移步至 Jest(https://jestjs.io/zh-Hans/docs/getting-started) 官方文檔。

作者:安風

來源:微信公衆号:政采雲技術

出處:https://mp.weixin.qq.com/s/74yodd86qn-Zn4AxTGp5kQ

繼續閱讀