如何使用 jest 和 lint-staged 只檢測發生改動的檔案

蚊子部落格發表於2021-06-23

我們現在在推進 EPC 的過程中，單元測試是必備的技能，在本地的 Git commit 之前進行單測非常有必要，總不能把所有的單測的壓力都放在流水線上。

畢竟在流水線執行單測的成本還是挺高的，從 push 上去觸發流水線，到感知單測的結果，至少需要好幾分鐘的時間。

棒棒噠-前端小茶館公眾號

因此我們有必要在 git commit 進行一些單測的檢測。不過若我們每次在 commit 之前都完整地執行所有的單測用例，一個是沒必要，再一個是耗時很長。

那應該怎麼只執行有變動的檔案的單測用例呢？

1. 使用 husky 和 lint-staged

我們接下來要使用 husky 和 lint-staged 元件，來實現在 commit 之前檢測只發生變動的檔案。

  • husky可以讓我們很方便地設定 pre-commit 的鉤子；
  • lint-staged元件能夠在 Git commit 提交之前，獲取上次 commit 到現在所有發生變動的檔案。我們可以利用這個特性來執行 jest；

1.1 配置 husky 和 lint-staged

首先我們來安裝和配置這兩個元件。

$ npm i husky lint-staged --save-dev
$ npm set-script prepare "husky install"
$ npm run prepare
$ npx husky add .husky/pre-commit "npx lint-staged"

執行完上述 4 個命令後，然後在package.json中配置 lint-staged：

{
  "scripts": {
    "test:staged": "jest --bail --findRelatedTests"
  },
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx}": ["npm run test:staged"]
  }
}

在 lint-staged 中支援node-glob萬用字元的配置，同時也支援配置多個，若發生變動的檔案路徑滿足配置，則觸發後面的命令。

上面萬用字元的意思是：src 目錄中任意路徑的任意以.js 或.jsx 或.ts 或.tsx 結尾的檔案。

拽拽的-前端小茶館公眾號

1.2 配置 jest

我們在上面的 test:staged 命令配置上了 jest。

  • bail: 只要遇到執行失敗的單測用例即退出；
  • findRelatedTests: 檢測指定的檔案路徑；

其他更多的引數，可以直接查閱官方文件Jest CLI Options。

很多公共的資料，我們可以直接在jest.config.js中進行配置：

module.exports = {
  roots: ['<rootdir>/src'], // 查詢src目錄中的檔案
  collectCoverage: true, // 統計覆蓋率
  coverageDirectory: 'coverage', // 覆蓋率結果輸出的資料夾
  coverageThreshold: {
    // 所有檔案總的覆蓋率要求
    global: {
      branches: 60,
      functions: 60,
      lines: 60,
      statements: 60,
    },
    // 匹配到的單個檔案的覆蓋率要求
    // 這裡也支援萬用字元的配置
    './src/**/*.{ts,tsx}': {
      branches: 40,
      functions: 40,
      lines: 40,
      statements: 40,
    },
  },
  // 匹配單測用例的檔案
  testMatch: ['<rootdir>/src/**/__tests__/**/*.{js,jsx,ts,tsx}', '<rootdir>/src/**/*.{spec,test}.{js,jsx,ts,tsx}'],
  // 當前環境是jsdom還是node
  testEnvironment: 'jsdom',
  // 設定別名，若不設定，執行單測時會不認識@符號
  moduleNameMapper: {
    '^@/(.*)$': '<rootdir>/src/$1',
  },
};

上面兩個配置完成後，當本次 commit 發生變動的檔案滿足要求，至少有 1 個檔案滿足時，則就會執行npm run test:staged。

我們先執行下所有的測試用例：

npm run test-前端小茶館公眾號

可以看到，我們實際上有 2 個原始檔，3 個測試檔案。不過 add 相關的已經在上次 commit 提交過了，本次提交時，只有 uitils 和 utils.test 有變動。

$ git add .
$ git ci -m 'test(utils): only test utils changed file'

從給出的測試報告能看出來，當前只檢測了發生變動的 utils 檔案：

test:staged-前端小茶館公眾號

2. 覆蓋率的要求

我們在上面通過 jest.config.js 中的coverageThreshold屬性，設定了全域性覆蓋率和單個檔案的覆蓋率。

我們再在程式碼新增幾個檔案，但不配置對應的測試檔案。然後執行時發現，如果沒有對應的測試檔案，就不會檢查該檔案的覆蓋率。

我這裡特意把概率設定 100%，然後 math.js 沒有對應的測試檔案：

覆蓋率-前端小茶館公眾號

從執行的測試結果來，這裡只檢測了有測試檔案的 utils.js，並沒有檢測到 math.js。

這裡我們就要新增一個屬性了collectCoverageFrom：

{
  collectCoverageFrom: ["src/**/*.{js,jsx,ts,tsx}"],
}

這時，我們再執行單測時，就能把所有符合要求的檔案，都納入到覆蓋率的考核裡了。

nice-前端小茶館公眾號

3. collectCoverageFrom 的坑

我們在使用 commit 提交時，會觸發lint-staged，按我們在第 1 節說的，應該只執行發生變動的例項，覆蓋率也只輸出當前執行的例項。

但實際上並不是如此，若配置了collectCoverageFrom，無論是怎樣執行單測，他都會輸出所有符合要求的檔案的覆蓋率資料：

lint-staged與collectCoverageFrom-前端小茶館公眾號

從黃色框框中可以看到，我們本次只提交了 utils.js，按說應該只執行和計算 utils.js 的單測覆蓋率即可，但實際上會把所有的覆蓋率都輸出出來，然後大部分資料為 0，無法滿足設定的覆蓋率的要求。

但我們又不能不設定 collectCoverageFrom 屬性，最後我的解決辦法是：排除法：

{
  collectCoverageFrom: ['!src/**/*.d.ts', '!src/**/*{.json,.snap,.less,.scss}'],
}

這樣我們在 commit 提交時，就能滿足只從被檢測的檔案中提取覆蓋率。

4. 總結

工欲興其事，必先利其器。當我們提前把配置搭建完成後，就可以進行開發啦。

王者嗎-前端小茶館公眾號

歡迎關注我的公眾號：“前端小茶館”。

前端小茶館公眾號

相關文章