• 前端測(cè)試感覺(jué)寫(xiě)起來(lái)很復(fù)雜，會(huì)花很多時(shí)間，甚至經(jīng)常是業(yè)務(wù)代碼時(shí)間的好幾倍
• 前端測(cè)試怎么TDD？
• 測(cè)試一些第三方UI控件時(shí)，特別難模擬與之的交互
• 有些東西不知道怎么mock，比如時(shí)間，瀏覽器全局變量（window.location，local storage）等
• 測(cè)試?yán)餃?zhǔn)備數(shù)據(jù)的代碼特別長(zhǎng)，真正的測(cè)試代碼很靠后，要翻很久，不容易定位
• 跑測(cè)試時(shí)會(huì)冒出很多Error或Warn Log，好像不影響測(cè)試通過(guò)，修起來(lái)也很花時(shí)間，還用修么？

?

在分享問(wèn)題的相關(guān)經(jīng)驗(yàn)之前，我們先來(lái)梳理一下前端測(cè)試體系~

前端測(cè)試體系

前端測(cè)試的重要性

這其實(shí)跟所有測(cè)試的重要性是一樣的，大家有這么多的痛點(diǎn)也是因?yàn)橹栏采w全面的測(cè)試可以對(duì)代碼質(zhì)量更有保證，讓我們更有信心地去重構(gòu)代碼，也能幫助我們更方便地了解現(xiàn)有的功能細(xì)節(jié)，甚至是一些極端的邊界情況。而且在大家合作開(kāi)發(fā)項(xiàng)目代碼的過(guò)程中，測(cè)試可以幫助我們更早地發(fā)現(xiàn)錯(cuò)誤，減少時(shí)間成本，提高交付效率。

前端測(cè)試方法論（TDD vs. BDD）

這兩個(gè)常見(jiàn)的測(cè)試方法論在這里簡(jiǎn)單介紹一下，就不大篇幅展開(kāi)了。TDD - (Test-Driven Development 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）簡(jiǎn)單地說(shuō)就是先根據(jù)需求寫(xiě)測(cè)試用例，然后實(shí)現(xiàn)代碼，通過(guò)后再接著寫(xiě)下一個(gè)測(cè)試和實(shí)現(xiàn)，循環(huán)直到全部功能和重構(gòu)完成?；舅悸肪褪峭ㄟ^(guò)測(cè)試來(lái)推動(dòng)整個(gè)開(kāi)發(fā)的進(jìn)行。BDD - (Behavior Driven Development 行為驅(qū)動(dòng)開(kāi)發(fā)) 其實(shí)可以看做是TDD的一個(gè)分支。簡(jiǎn)單地說(shuō)就是先從外部定義業(yè)務(wù)行為，也就是測(cè)試用例，然后由外入內(nèi)的實(shí)現(xiàn)這些行為，最后得到的測(cè)試用例也是相應(yīng)業(yè)務(wù)行為的驗(yàn)收標(biāo)準(zhǔn)。

前端測(cè)試的分層

在這里借一下前端大牛Kent C. Dodds的獎(jiǎng)杯分層法來(lái)引出常見(jiàn)的分類(lèi)：

（圖片出處：https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests）

端到端測(cè)試 End to End Test

端到端測(cè)試一般會(huì)運(yùn)行在完整的應(yīng)用系統(tǒng)上（包括前端和后端），包含用戶完整的使用場(chǎng)景，比如打開(kāi)瀏覽器，從注冊(cè)或登錄開(kāi)始，在頁(yè)面內(nèi)導(dǎo)航，完成系統(tǒng)提供的功能，最后登出。

有時(shí)，我們也會(huì)在這里引入可視化用戶界面測(cè)試，即一種通過(guò)像素級(jí)比較屏幕截屏來(lái)驗(yàn)證頁(yè)面顯示是否正確的測(cè)試。目的是確保界面在不同設(shè)備、瀏覽器、分辨率和操作系統(tǒng)下與預(yù)期的樣式一致?？梢栽O(shè)置一定的偏差容忍值。這一層的測(cè)試成本較高，所以通常重心會(huì)放在確保主流程的功能正常上。常用工具：Cypress、Playwright、Puppeteer、TestCafe、Nightwatch （下載量對(duì)比）

集成測(cè)試主要是測(cè)試當(dāng)單元模塊組合到一起之后是否功能正常。在不同的測(cè)試上下文下可能有不同的定義，在前端測(cè)試這里通常指測(cè)試集成多個(gè)單元組件到一起的組件。

單元測(cè)試 Unit Test

單元測(cè)試就是對(duì)沒(méi)有依賴(lài)或依賴(lài)都被mock掉了的測(cè)試單元的測(cè)試。在前端代碼里，它可能是：

• 沒(méi)有依賴(lài)或依賴(lài)都被mock掉了的單元組件
• 功能代碼如Utils/Helpers等公共方法集合的測(cè)試
• 輔助組件功能如React Hook / Selector等公共方法的測(cè)試

靜態(tài)代碼測(cè)試 Static Test

主要是指利用一些代碼規(guī)范工具(Lint Tool)來(lái)及時(shí)捕獲代碼中潛在的語(yǔ)句錯(cuò)誤，統(tǒng)一代碼格式等。這里就不展開(kāi)了。常見(jiàn)工具和實(shí)踐有：

• Eslint + Prettier 代碼規(guī)范和樣式統(tǒng)一
• husky + lint-staged (gitHooks工具）可以自動(dòng)在commit和push之前進(jìn)行代碼掃描，阻止不規(guī)范代碼進(jìn)入代碼庫(kù)，也可以設(shè)置在push之前跑一遍前端測(cè)試

前端測(cè)試策略

還是這張圖，我標(biāo)記了一下：

• 越往上成本越高
• 越往上得到反饋的速度越慢
• 但越往上，越貼近最終用戶的行為，越能發(fā)現(xiàn)真實(shí)的問(wèn)題，能給到的信心就更多

在獎(jiǎng)杯的形狀上每一層占的面積代表了應(yīng)該投入的重心比例。

這里集成測(cè)試的比重比單元測(cè)試大是因?yàn)榧蓽y(cè)試可以在成本很高的e2e測(cè)試和離最終用戶行為較遠(yuǎn)的單元測(cè)試之間取的一個(gè)平衡，它可以寫(xiě)的很接近最終用戶的行為，成本又相對(duì)的沒(méi)那么高，屬于性?xún)r(jià)比很高的一部分。

所以集成測(cè)試有一些原則：

• 可以根據(jù)每個(gè)頁(yè)面的復(fù)雜程度決定是只有一個(gè)全頁(yè)面的集成測(cè)試還是可以劃分成幾大塊分別有集成測(cè)試，但一旦作為集成測(cè)試，就要盡可能的少mock依賴(lài)，盡量的渲染全子組件
• 盡量測(cè)試用戶的所見(jiàn)和交互，而不是背后的實(shí)現(xiàn)，否則就會(huì)遠(yuǎn)離最終用戶行為，降低信心值，而且隨著代碼的重構(gòu)，測(cè)試也需要頻繁的修改。比如Enzyme可以把component里的方法、props、state等都提供出來(lái)單獨(dú)測(cè)試，但這里的測(cè)試并不貼近真實(shí)用戶的交互，很容易就會(huì)因?yàn)橹貥?gòu)而破壞測(cè)試，更好的方法是真的去測(cè)試當(dāng)props和state變化后頁(yè)面的變動(dòng)，或交互的變化
• 準(zhǔn)備的測(cè)試數(shù)據(jù)盡量豐富且貼近真實(shí)數(shù)據(jù)（用戶敏感信息要替換掉），越貼近真實(shí)的數(shù)據(jù)越能覆蓋到更多真正的問(wèn)題
• 對(duì)于核心的業(yè)務(wù)行為，要重點(diǎn)測(cè)試

對(duì)于單元測(cè)試來(lái)說(shuō)：

• UI組件類(lèi)的測(cè)試：因?yàn)橛辛思蓽y(cè)試的覆蓋，可以簡(jiǎn)單的測(cè)試一下不同props的渲染，如果有一些集成測(cè)試覆蓋不到的特殊數(shù)據(jù)引發(fā)的交互行為，可以測(cè)試一下
• 非UI組件類(lèi)的測(cè)試：通常會(huì)覆蓋一些復(fù)雜的業(yè)務(wù)邏輯，需要全面的測(cè)試一下不同的分支條件

前端測(cè)試工具的分類(lèi)

測(cè)試啟動(dòng)工具 (Test Launchers)

測(cè)試啟動(dòng)工具負(fù)責(zé)將測(cè)試運(yùn)行在Node.js或?yàn)g覽器環(huán)境。形式可能是CLI或UI，并結(jié)合一定的配置。常見(jiàn)工具有：Jest / Karma / Jasmine / Cypress / TestCafe 等。

測(cè)試結(jié)構(gòu)工具 (Structure Providers)

測(cè)試結(jié)構(gòu)工具提供一些方法和結(jié)構(gòu)將測(cè)試組織的更好，擁有更好的可讀性和可擴(kuò)展性。如今，測(cè)試結(jié)構(gòu)通常以BDD形式來(lái)組織。測(cè)試結(jié)構(gòu)如下方Jest例子：

// Jest test structure
describe('calculator', () => {
  // 第一層級(jí): 標(biāo)明測(cè)試的模塊名稱(chēng)
    beforeEach(() => {
        // 每個(gè)測(cè)試之前都會(huì)跑，可以統(tǒng)一添加一些mock等
    })
    afterEach(() => {
        // 每個(gè)測(cè)試之后都會(huì)跑，可以統(tǒng)一添加一些清理功能等
    })
  describe('add', () => {
    // 第二層級(jí): 標(biāo)明測(cè)試的模塊功能分組
    test('should add two numbers', () => {
       // 實(shí)際的描述業(yè)務(wù)需求的測(cè)試
       ...
    })
  })
})

常見(jiàn)工具有：Jest / Mocha / Cucumber / Jasmine / Cypress / TestCafe 等。

斷言庫(kù) (Assertion Functions)

斷言庫(kù)會(huì)提供一系列的方法來(lái)幫助驗(yàn)證測(cè)試的結(jié)果是否符合預(yù)期。如下方的例子：

// Jest expect (popular)
expect(foo).toEqual('bar')
expect(foo).not.toBeNull()

// Chai expect
expect(foo).to.equal('bar')
expect(foo).to.not.be.null

常見(jiàn)工具有：Jest / Chai / Assert / TestCafe 等。

Mock工具

有的時(shí)候我們?cè)跍y(cè)試的時(shí)候需要隔離一些代碼，模擬一些返回值，或監(jiān)控一些行為的調(diào)用次數(shù)和參數(shù)，比如網(wǎng)絡(luò)請(qǐng)求的返回值，一些瀏覽器提供的功能，時(shí)間計(jì)時(shí)等，Mock工具會(huì)幫助我們更容易的去完成這些功能。

常見(jiàn)工具有：Sinon / Jest (spyOn, mock, useFakeTimers…) 等。

快照測(cè)試工具 (Snapshot Comparison)

快照測(cè)試對(duì)于UI組件的渲染測(cè)試十分有效。原理是第一次運(yùn)行時(shí)生成一張快照文件，需要開(kāi)發(fā)人員確認(rèn)快照的正確性，之后每一次運(yùn)行測(cè)試都會(huì)生成一張快照并與之前的快照做比較，如果不匹配，則測(cè)試失敗。這時(shí)如果新的快照確實(shí)是更新代碼后的正確內(nèi)容，則可以更新之前保存的快照。（這里的快照通常都是框架渲染器生成的序列化后的字符串，而不是真實(shí)的圖片，這樣的測(cè)試效率比較高）。

這里可以參考Jest官方的用例。

常見(jiàn)工具有：Jest / Ava / Cypress

測(cè)試覆蓋率工具（Test Coverage）

測(cè)試覆蓋率工具可以產(chǎn)出測(cè)試覆蓋率報(bào)告，通常會(huì)包含行、分支、函數(shù)、語(yǔ)句等各個(gè)維度的代碼覆蓋率，還可以生成可視化的html報(bào)告來(lái)可視化代碼覆蓋率。如以下的Jest內(nèi)置的代碼覆蓋率報(bào)告：

（圖片出處：??https://jestjs.io/）??

常見(jiàn)工具有：Jest內(nèi)置 / Istanbul。

E2E 測(cè)試工具（End to End Test）

上面在測(cè)試分層里介紹過(guò)的。

可視化用戶界面測(cè)試（Visual Regression）

也在上面的測(cè)試分層里介紹過(guò)。通常會(huì)和e2e測(cè)試工具組合在一起使用，一般主流的e2e測(cè)試工具也會(huì)有對(duì)應(yīng)的庫(kù)去進(jìn)行可視化用戶界面測(cè)試。

前端框架專(zhuān)屬測(cè)試庫(kù)

不同的前端框架還會(huì)有一些自帶的或推薦的測(cè)試庫(kù)，比如：

• React: React官方的Test Utils / Testing Library - React（推薦） / Enzyme （基于上面的測(cè)試策略，更推薦React Testing Library，Enzyme暴露了太多內(nèi)部元素用來(lái)測(cè)試，雖然一時(shí)方便，但遠(yuǎn)離了用戶行為，之后帶來(lái)的修改頻率也比較高，性?xún)r(jià)比低）
• Vue: Vue官方的Test Utils / Testing Library - Vue
• Angular: Angular內(nèi)置的測(cè)試框架(Jasmine) / Testing Library - Angular

前端測(cè)試框架

基于上面的分類(lèi)，大家可能發(fā)現(xiàn)幾乎哪哪都有Jest，這類(lèi)大而全的前端測(cè)試工具我們也可以稱(chēng)為前端測(cè)試框架。

常見(jiàn)的有：

• Jest：大力推薦，幾乎有測(cè)試需要的所有工具，社區(qū)活躍，網(wǎng)上資源豐富，也是React官方推薦的測(cè)試框架
• Mocha：雖然也功能豐富，但沒(méi)有斷言庫(kù)、測(cè)試覆蓋率工具和Mock工具，需要和其他第三方庫(kù)配合使用
• Jasmine：比較老派的工具，功能也沒(méi)有Jest豐富，下載率逐年下降

最后附上一張stateOfJS網(wǎng)站2021年的測(cè)試庫(kù)滿意度圖表供大家參考 ：

（圖片出處：https://2021.stateofjs.com/en-US/libraries/testing/）

前端測(cè)試的常見(jiàn)問(wèn)題

終于回到最開(kāi)始的問(wèn)題了，分享一下我的經(jīng)驗(yàn)和通常的解決辦法：

前端測(cè)試感覺(jué)寫(xiě)起來(lái)很復(fù)雜，會(huì)花很多時(shí)間，甚至經(jīng)常是業(yè)務(wù)代碼時(shí)間的好幾倍，這個(gè)問(wèn)題可以分成三部分來(lái)下手：

優(yōu)化測(cè)試策略

可以根據(jù)剛才的測(cè)試策略部分，結(jié)合自己項(xiàng)目的實(shí)際情況，調(diào)整一下在不同的測(cè)試層分配的重心，定一下自己項(xiàng)目每個(gè)層級(jí)的測(cè)試粒度，這樣才能在保證交付的前提下達(dá)到測(cè)試信心值收益的最大化。

提升寫(xiě)測(cè)試效率

(1) 抽取公共的部分，使具體的測(cè)試文件簡(jiǎn)潔

• 準(zhǔn)備數(shù)據(jù)的fixture庫(kù)，可以輕松的生成想要的store數(shù)據(jù)或請(qǐng)求返回?cái)?shù)據(jù)
• 公共的render方法，可以支持自定義store, stub子組件, mock框架全局方法等
• 公共的第三方UI組件交互方法，可以輕松的觸發(fā)第三方控件的事件，不用再關(guān)心實(shí)現(xiàn)細(xì)節(jié)
• 公共的api mock方法，可以在測(cè)試文件里不用關(guān)心api細(xì)節(jié)，輕松mock

(2) 統(tǒng)一測(cè)試規(guī)范，有優(yōu)化及時(shí)重構(gòu)所有測(cè)試，這樣大家可以放心的參考已有測(cè)試，不會(huì)有多種寫(xiě)法影響可讀性

提升運(yùn)行測(cè)試的效率

• 并行跑測(cè)試
• 測(cè)試?yán)锍Ｓ萌缦路椒ㄊ勾郎y(cè)的異步請(qǐng)求返回，通常也會(huì)給setTimeout一個(gè)等待時(shí)間，大部分的情況0就可以達(dá)到目的了，除非是邏輯真的要等待一定的時(shí)間，如果默認(rèn)值都設(shè)置的比較大，每個(gè)測(cè)試都會(huì)耽誤一些時(shí)間，加起來(lái)對(duì)測(cè)試運(yùn)行性能的影響是很大的

// testUtils.js
export const flushPromises = (interval = 0) => {
  return new Promise((resolve) => {
    setTimeout(resolve, interval);
  });
};

// example.test.js
test('should show ...', async () => {
  //render component
  await flushPromises();
    //verify component
});

前端測(cè)試怎么TDD

通常問(wèn)這個(gè)問(wèn)題背后隱藏的問(wèn)題是前端很難先寫(xiě)測(cè)試，再寫(xiě)實(shí)現(xiàn)。確實(shí)我也有同感，如果是一些util/helper方法是可以很容易的遵循TDD的步驟的，但當(dāng)涉及頁(yè)面結(jié)構(gòu)和樣式的時(shí)候，很難在寫(xiě)測(cè)試的時(shí)候就想清楚頁(yè)面到底有哪些具體的元素，用到哪些需要mock的模塊。

所以在測(cè)試UI組件時(shí)，我通常會(huì)使用BDD的方式，具體步驟是：

• 建立組件文件，渲染返回空
• 建立測(cè)試文件，先寫(xiě)一個(gè)snapshot測(cè)試，測(cè)試會(huì)通過(guò)，生成一個(gè)snapshot文件
• 再根據(jù)這個(gè)頁(yè)面mockup上已知的交互寫(xiě)好test case，通常這個(gè)時(shí)候不太容易寫(xiě)實(shí)現(xiàn)，就先把測(cè)試用例都寫(xiě)好，test先skip起來(lái)，eslint可以設(shè)置成skip的test用warn來(lái)展示，這樣之后方便補(bǔ)全

// Jest
describe('todo component', () => {
  test('should show todo list', () => {
     // Snapshot test
        const tree = renderer.create(<Todo />).toJSON();
    expect(tree).toMatchSnapshot();
  })

  test.skip('should add todo when click add and input todo content', () => {
  })

  test.skip('should remove todo when click delete icon of todo item', () => {
  })

• 隨著頁(yè)面重構(gòu)，可能會(huì)給組件添加props，這時(shí)也需要給不同的props添加snapshot測(cè)試或交互測(cè)試
• 最后可以根據(jù)測(cè)試跑完的測(cè)試覆蓋率報(bào)告看看是否覆蓋全面了，防止有遺漏

當(dāng)然隨著前端代碼寫(xiě)的越來(lái)越熟練，為了提升效率，有時(shí)會(huì)簡(jiǎn)化步驟，等一個(gè)小功能的組件都重構(gòu)完了，樣式調(diào)好了，所有的子組件都抽完了，再根據(jù)每個(gè)組件的props和交互的點(diǎn)批量加測(cè)試，最后用測(cè)試覆蓋率來(lái)驗(yàn)證是否都覆蓋到了，保證自己新寫(xiě)的組件都盡可能是100%的覆蓋率。

測(cè)試一些第三方UI控件時(shí)，特別難模擬與之的交互

這個(gè)是我也很頭疼的問(wèn)題，有的時(shí)候一些第三方組件因?yàn)橐獙?shí)現(xiàn)一些復(fù)雜的效果，會(huì)使用不一樣的方式去監(jiān)聽(tīng)事件。

比如我們有一個(gè)Vue項(xiàng)目上用到了element-ui的select組件，這個(gè)組件可以通過(guò):remote-method 屬性開(kāi)啟異步發(fā)請(qǐng)求加載選項(xiàng)的功能，測(cè)試?yán)锵肽M異步拿到選項(xiàng)后并選擇某選項(xiàng)，就需要想辦法觸發(fā)它的@change 事件，通常一條await fireEvent.update(input, 'S'); 就搞定了，但這個(gè)怎么都不生效，仔細(xì)的查看它的實(shí)現(xiàn)才發(fā)現(xiàn)需要這么一串操作才能觸發(fā)到@change 事件。

const input = getByPlaceholderText('Please input to search');
await fireEvent.click(input);
await fireEvent.keyUp(input, { key: 'A', code: 'KeyA' });
await fireEvent.update(input, 'A');
await flushPromises(500); // 這個(gè)方法上面有介紹，的作用是讓異步的代碼返回結(jié)果，并且等待500ms，因?yàn)樵创a有500ms的等待，這里就也需要等待
await fireEvent.click(getByText('Apple'));

這里我總結(jié)的經(jīng)驗(yàn)就是：

• 如果發(fā)現(xiàn)常用的交互方法不能生效，需要去研究第三方組件的源碼
• 更重要的是如果大家研究出來(lái)了方法，及時(shí)的把相關(guān)代碼抽到一個(gè)公共的util文件里，這樣之后就不會(huì)有人也花費(fèi)很多時(shí)間在上面了，確實(shí)經(jīng)常遇到大家重復(fù)卡在相同的第三方組件交互問(wèn)題上而不知道已經(jīng)有代碼解決了的場(chǎng)景

有些東西不知道怎么mock，比如時(shí)間，瀏覽器全局變量（window.location，local storage）等

這個(gè)可以結(jié)合使用的測(cè)試工具去搜索，一般都會(huì)有很多現(xiàn)成的解決方案，在這里舉兩個(gè)例子：

Mock navigator.userAgent：：

// jest.setup.js
Object.defineProperty(
  global.navigator,
  'userAgent',
  ((value) => ({ 
        get() { return value; }, 
        set(v) { value = v; },
  }))(global.navigator['userAgent']),
);

// example.test.js
test('should show popup in Safari', () => {
  global.navigator.userAgent = 'user agent of Safari ...';
    // render and verify something
});

Mock window.open：

//jest.setup.js
Object.defineProperty(
  window,
  'open',
  ((value) => ({
        get() { return value; }, 
        set(v) { value = v; },
  }))(window.open),
);
// example.test.js
test('should ...', () => {
    window.open = jest.fn();
    // render something
    expect(window.open).toBeCalledWith('xxx', '_blank');
});

測(cè)試?yán)餃?zhǔn)備數(shù)據(jù)，mock依賴(lài)的代碼特別長(zhǎng)，真正的測(cè)試代碼很靠后，要翻很久，不容易定位

上面有介紹，可以將公共的部分抽取出去，又能減少代碼重復(fù)，又能提升寫(xiě)測(cè)試的效率，比如準(zhǔn)備數(shù)據(jù)的部分可以抽成公共的fixture文件，提供方法生成默認(rèn)的數(shù)據(jù)，也可以通過(guò)參數(shù)去覆蓋修改部分?jǐn)?shù)據(jù)，達(dá)到定制化的目的：

export const generateUser = (user = {}) => {
  return {
    id: 1,
    firstName: 'San',
    lastName: 'Zhang',
    email: 'sanzhang@test.com',
    ...user,
  };
};

跑測(cè)試時(shí)會(huì)冒出很多Error或Warn Log，好像不影響測(cè)試通過(guò)，修起來(lái)也很花時(shí)間，還用修么？

測(cè)試?yán)锏膱?bào)錯(cuò)通常都很有價(jià)值，需要重視。這里面的錯(cuò)誤有可能是：

• 前端框架相關(guān)的，比如被測(cè)的組件有寫(xiě)的或調(diào)用的不合理的情況，這種有的時(shí)候不僅是測(cè)試調(diào)用組件方式的問(wèn)題，有可能業(yè)務(wù)代碼也寫(xiě)的有問(wèn)題；或者是測(cè)試語(yǔ)句寫(xiě)的不合理，如React的 not wrapped in act(...)
• 測(cè)試運(yùn)行相關(guān)的，比如有些請(qǐng)求沒(méi)有mock，測(cè)試?yán)镆恢钡炔坏椒祷刂刀鴗imeout了，但又不是主測(cè)的業(yè)務(wù)，所以測(cè)試還是會(huì)通過(guò)，之前有遇到很多次測(cè)試并行跑時(shí)會(huì)互相影響，隨機(jī)掛，如果log里有類(lèi)似這種timeout的內(nèi)容，很有可能就是原因，mock好了所有的請(qǐng)求后問(wèn)題就解決了

雖然有的時(shí)候也會(huì)有一些由于第三方庫(kù)的原因引起的無(wú)法修復(fù)又沒(méi)有影響的log，可以忽略，但測(cè)試?yán)锎蟛糠志鍸og其實(shí)都是可以修復(fù)的，甚至在修復(fù)后可能得到意想不到的受益，比如發(fā)現(xiàn)真正業(yè)務(wù)代碼的問(wèn)題，測(cè)試不再隨機(jī)掛了，測(cè)試運(yùn)行性能提升了等等。

總結(jié)

對(duì)于前端測(cè)試，我覺(jué)得重心不是機(jī)械的去追求測(cè)試覆蓋率，而是盡可能的在成本和信心值中間找到一個(gè)平衡，應(yīng)用一些好的實(shí)踐去降低寫(xiě)測(cè)試的成本，提升寫(xiě)測(cè)試帶來(lái)的回報(bào)，讓大家對(duì)于項(xiàng)目質(zhì)量越來(lái)越有信心。

原文鏈接：??前端測(cè)試體系和最佳實(shí)踐 (qq.com)??