【深度好文，值得萬轉】再也不痛失薪資上調和年終獎，快來試試自動化測試！！！

 

這篇文章是前端自動化測試系列的開始，自動化測試系列會從理論走向實踐，真正帶領你們學會使用前端自動化測試框架，並能在業務中落地。

看完整個系列，還不會使用自動化測試工具爲生產提效，請來找我！

點贊數過一百，下週更新前端自動化測試與 React 的結合，如何在 React 項目中落地，歡迎你們多多點贊評論收藏！大家的讚揚是我寫做最大的動力！

以前發沸點說掘金髮文只發精品文，閱讀量最少 3k，看看此次行不行。

悄悄說一句，文末有福利！

 

衆所周知的緣由，前端做爲一種特殊的 GUI 軟件，作自動化測試困難重重。在快速迭代，UI 變更大的業務中，自動化測試想要落地更是男上加男 :dog:。

近期的學習過程當中，翻閱了衆多前端自動化測試相關的文章， 「 大多數都在講如何使用自動化測試框架對前端代碼進行測試，不多講解爲何要引入自動化測試，引入自動化測試有哪些好處，哪些項目適合引入自動化測試 」 ，但這些纔是真正咱們想要知道的。

考慮到各位讀者爸爸們可能沒有接觸過自動化測試的內容，這篇文章就從基本概念和基礎用法入手，爲你們講解自動化測試的內容。

開始以前，先進行一下前戲（可能比較長，不喜歡的能夠快進 :dog:）：

 

情景還原

 

小王是國內一家大廠的前端開發。就在述職前一週，產品經理給了一個需求，要求在老項目上加上新的功能。

小王打開老項目代碼，定睛一看，心頭一緊 —— 要改的組件已經長達 800 多行，快速掃一眼，發現尚未註釋。 小王哭了，但產品經理要求 3 天內實現新功能，沒辦法，只能硬着頭皮寫了。

小王準備開始寫了，對新功能大體作了一下技術分析，發現與老代碼的耦合比較厲害，因而就開始一邊寫，一邊閱讀和修改老代碼。

「 老代碼又臭又長，小王發現有一段代碼不知道爲何要對輸入文本作處理，以爲是一段沒有用的代碼，還影響到本身添加新功能，因而小王把這段代碼刪掉了。 」

新功能定期完成，小王通過了簡單的手工自測，沒有問題，因而就發送了提測郵件，等待測試反饋，開開心心準備述職去了。

對新功能的測試也順利經過，小王將新功能發佈上線，結束了這周的工做，回家享受週末了。

小王早早地洗漱完上牀睡覺了，忽然大半夜老闆打電話過來：小王，快起來，出 BUG 了，影響了 1w+ 的用戶，快起來看看什麼問題！

小王猛地起身，從揹包裏取出電腦，開始排查 BUG 出現的緣由，一頓 debug 以後，發現 「 居然是本身刪掉的那段老代碼致使了 BUG 」 ！

小王又一次哭了，修復好 BUG，緊急發佈上線。

「下週一就述職了，今天出這麼個 BUG，年終獎確定沒了，普調估計也懸。還要寫 case 報告抄送大部門，丟人丟到家了。」

可是若是公司的老項目引入了自動化測試，後來的故事就徹底不同了：

情景反轉

小王準備開始寫了，對新功能大體作了一下技術分析，發現與老代碼的耦合比較厲害，因而就開始一邊寫，一邊閱讀和修改老代碼。

老項目的前端開發爲了保證項目可以正常運行，編寫了單元測試和集成測試的代碼，在 README 裏要求維護的同事要在添加/修改了代碼以後跑一遍測試用例。

「 老代碼又臭又長，小王發現有一段代碼不知道爲何要對輸入文本作處理，以爲是一段沒有用的代碼，還影響到本身添加新功能，因而小王把這段代碼刪掉了。 」

小王刪掉代碼以後跑測試用例，忽然好幾個刺眼的紅色字符映入眼簾 —— 「 FAIL TO TEST 」

一看測試用例描述，小王這才知道這段代碼的做用。因而小王對這段代碼作了重構，同時也加上了新功能，跑一遍測試用例 —— 全是綠色的 「 PASS 」 。

小王長舒一口氣，給本身的新功能也加上了測試用例，修修改改讓新加的測試用例也跑通了。

雖然小王由於編寫測試用例稍微加班了一會，可是他感受一身輕鬆，很是有安全感。

提測、發佈一切正常，小王享受了一個愉快的週末。

下週回來以後述職，心情大好，狀態極佳，獲得老闆們的讚揚。績效評定棒棒噠，年終獎和普調都沒問題。

上面的故事都是我 YY 的，若有雷同純屬巧合 :dog:。

什麼是測試？

 

 

測試其實就是在已經開發完成的軟件之上採用 「 人工或非人工 」 的方式驗證軟件是否符合工程預期，是否會形成用戶/開發商損失等潛在問題的一種方式。

大多數狀況下，咱們編寫的前端代碼都是開發手工自測，又或是提測後由專門的測試人員手工測試。

手工測試固然也是沒有問題的，可是經過自動化的測試工具，能夠更加快速高效且準肯定位問題所在。

自動化測試其實是運行一段測試代碼，去驗證目標代碼是否知足某個指望。

本文後續的內容中， 「 「測試」一詞將專門指代自動化測試 」 。

爲何要測試？

 

 

咱們進行測試的目的在於，及時發現錯誤，提升代碼質量和開發效率，避免存在 BUG 的代碼發佈上線形成損失。

「 測試自動化的好處在於反饋及時，可以極大地提升前端的開發效率。 」

在咱們平常的開發過程當中，是否是常常須要在項目跑起來以後去人工測試某些操做或者流程是否可以正常運行？是否是常常須要打斷點或者使用 console.log 查看控制檯信息來檢查某個函數是否執行？

這些須要咱們本身手工測試代碼的執行結果是否符合預期的場景，徹底可使用自動化測試的腳本代替。

現有的不少成熟的自動化測試框架徹底能夠模擬咱們的手工操做，使用腳本自動運行測試用例，一般只須要幾秒就能給出準確的反饋，同時還能偵聽代碼變化，自動執行項目中發生了變化的代碼對應的測試用例，可以極大提升咱們的開發效率。

在公司業務和人員變更都比較快的當下，編寫自動化測試腳本的收益愈來愈高。開發者不再用懼怕引入迴歸 BUG，也不再用懼怕把代碼交給他人維護。有了測試腳本的約束，迭代/重構都能更加從容。

❝

 

❞

有哪些測試類型？

前端測試主要分爲 3 種： 「 單元測試（Unit Test） 」 、 「 集成測試（Integration Test） 」 、 「 UI 測試（UI Test） 」

三種測試的佔比分別爲：

 

現實是，大多數公司的測試金字塔是倒過來的，由人工進行 「 UI 測試 」 反而是最多的， 「 集成測試 」 和 「 單元測試 」 卻大多被忽略。

單元測試（Unit Test）

單元測試是最容易實現的：代碼中多個組件共用的工具類庫、多個組件共用的子組件等。

「 一般狀況下，在公共函數/組件中必定要有單元測試來保證代碼可以正常工做。單元測試也應該是項目中數量最多、覆蓋率最高的。 」

能進行單元測試的函數/組件，必定是低耦合的，這也從必定程度上保證了咱們的代碼質量。

集成測試（Integration Test）

集成測試一般被應用在：耦合度較高的函數/組件、通過二次封裝的函數/組件、多個函數/組件組合而成的函數/組件等。

集成測試的目的在於，測試通過單元測試後的各個模塊組合在一塊兒是否能正常工做。會對組合以後的代碼總體暴露在外接口進行測試，查看組合後的代碼工做是否符合預期。

「 集成測試是安全感較高的測試，能很大程度提高開發者的信心，集成測試用例設計合理且測試都經過可以很大程度保證產品符合預期。 」

UI 測試（UI Test）

在我學習查閱文獻的過程當中，我發現國內很多文章都將 UI 測試（UI Test）和端到端測試（E2E Test）混爲一談，認爲是同一個測試類型。

事實上，UI 測試（UI Test）和端到端測試（E2E Test）是稍有區別的：

 

UI 測試（UI Test）只是對於前端的測試，是脫離真實後端環境的，僅僅只是將前端放在真實環境中運行，然後端和數據都應該使用 Mock 的。

端到端測試（E2E Test）則是將整個應用放到真實的環境中運行，包括數據在內也是須要使用真實的。

 

就前端而言，UI 測試（UI Test）更貼近於咱們的開發流程。在先後端分離的開發模式中，前端開發一般會使用到 Mock 的服務器和數據。於是咱們須要在開發基本完成後進行相應的 UI 測試（UI Test）。

UI 測試的自動化程度還不高，大多數還依賴於手工測試。

在一些自動化測試工具中有建立快照的功能，也能幫助咱們在必定程度上實現 UI 測試（UI Test）的自動化。

哪些項目適合引入自動化測試？

目前市面上的大多數文章都沒有講過這個問題，但事實上這個問題是最值得思考的！

在化學上有一句名言：

 

拋開劑量談毒性都是耍流氓。

 

「 同理，在前端自動化測試方面，拋開項目類型、軟件開發的人員配置和生命週期而談論自動化測試的好處和必要性，也是耍流氓。 」

於我我的而言，我比較喜歡寫測試代碼，當看到測試用例都所有 PASS 都是綠色的時候，很是舒服。

但我猜大部分的開發都會以爲：需求這麼多，這麼緊急，保證完成需求都已經很是困難了，已經沒精力再編寫測試代碼了。

現實中，咱們常常會針對一些活動開發一些一次性的代碼模塊，這樣的代碼模塊功能簡單，且後續繼續迭代的可能性低，這種代碼就徹底沒有必要引入自動化測試工具。

「 適合引入自動化測試的場景： 」

1. 公共庫類的開發維護

2. 中長期項目的迭代/重構

3. 引用了不可控的第三方依賴

這些場景是須要引入自動化測試來對現有代碼進行約束的。 「 尤爲是中長期項目，迭代/重構時人力迴歸困難，自動化測試就顯得尤其重要！ 」

如何選擇測試工具？

如今市面上有不少流行的測試工具，但廣泛都存在一個問題： 「 新特性的支持滯後 」 。

前端測試的框架可謂是百花齊放。

• 單元測試（Unit Test）有 Mocha, Ava, Karma, Jest, Jasmine 等。

• 集成測試（Integration Test）和 UI 測試（UI Test）有 ReactTestUtils, Test Render, Enzyme, React-Testing-Library, Vue-Test-Utils 等。

 

主流測試工具比較

框架	斷言	仿真	快照	異步測試
Mocha	默認不支持，可配置	默認不支持，可配置	默認不支持，可配置	友好
Ava	默認支持	不支持，需第三方配置	默認支持	友好
Jasmine	默認支持	默認支持	默認支持	不友好
Jest	默認支持	默認支持	默認支持	友好
Karma	不支持，需第三方配置	不支持，需第三方配置	不支持，需第三方配置	不支持，需第三方配置

• Mocha 是生態最好，使用最普遍的單測框架，可是他須要較多的配置來實現它的高擴展性。

• Ava 是更輕量高效簡單的單測框架，可是自身不夠穩定，併發運行文件多的時候會撐爆 CPU。

Jasmine

• Jasmine 是單測框架的「元老」，開箱即用，可是異步測試支持較弱。

• Jest 基於 Jasmine, 作了大量修改並添加了不少特性，一樣開箱即用，但異步測試支持良好。

• Karma 能在真實的瀏覽器中測試，強大適配器，可配置其餘單測框架，通常會配合 Mocha 或 Jasmine 等一塊兒使用。

每一個框架都有本身的優缺點，沒有最好的框架，只有最適合的框架。Augular 的默認測試框架就是 Karma + Jasmine，而 React 的默認測試框架是 Jest。

Jest 被各類 React 應用推薦和使用。它基於 Jasmine，至今已經作了大量修改並添加了不少特性，一樣也是開箱即用，支持斷言，仿真，快照等。Create React App 新建的項目就會默認配置 Jest，咱們基本不用作太多改造，就能夠直接使用。

採用何種測試思想？

TDD：Test-Driven Development（測試驅動開發）

• TDD：Test-Driven Development（測試驅動開發）：TDD 則要求在編寫某個功能的代碼以前先編寫測試代碼，而後只編寫使測試經過的功能代碼，經過測試來推進整個開發的進行

BDD：Behavior-Driven Development（行爲驅動開發）

• BDD：Behavior-Driven Development（行爲驅動開發）：BDD 可讓項目成員（甚至是不懂編程的）使用天然語言來描述系統功能和業務邏輯，從而根據這些描述步驟進行系統自動化的測試

Jest 基本語法

「 因爲大廠廣泛使用 React/Vue 進行開發，而 React/Vue 官方推薦的單元測試工具都是 Jest，所以本文咱們就簡單介紹一下 Jest 的基本語法。 」

 

 匹配器(Number)

匹配器(String)

Array & Iterable

 

 

匹配器(Array & Iterable)

 

Exception

 

匹配器(Exception)

 

異步代碼測試

 

異步代碼測試

 

異步代碼測試

 

推薦方法

 

生命週期鉤子

 

 

生命週期鉤子

 

 

「 生命週期鉤子執行順序符合洋蔥模型。 」

執行順序

 

執行順序

「 測試單元/用例執行順序相似異步隊列 」

函數 Mock

 

函數 Mock

 

 

 函數 Mock

本篇文章介紹了前端自動化測試的一些基本概念和主流測試框架 Jest 的基礎用法。

相信看完本篇爲文章，你必定對前端自動化測試有了必定的瞭解。

點贊過一百，下一篇將會爲你們帶來自動化測試框架 Jest 與 React 的配合，讓你們真正可以在 React 的項目中落地，爲生產提效！

文末福利

最近看到一些大廠的秋招提早批開始了，鋪天蓋地的內推碼。

「 卻不知就算有了內推碼投了簡歷，也有可能由於簡歷製做不到位、面試不懂得技巧等各類各樣的緣由與大廠失之交臂！ 」

 

 加入咱們的qq交流會，313782132

 

 

 

 大廠大牛詳細講解，面試經驗、學習資料。