寫了一本開源小書《Jest 實踐指南》

哈嘍，大家好，我是海怪。

前段時間一直在給公司項目引入 Jest，這過程中學到了不少東西，也查了很多相關(guān)資料。最后編寫了一本小書《Jest 實踐指南》^[1]， 希望能幫助到想了解和學習前端測試的朋友。

• 教程首頁^[2]
• 教程 Github^[3]
• 教程配套項目 Github^[4]

測試難點

Jest 看似很簡單，就像很多博客寫的那樣：

expect(sum(1,?1)).toEqual(2)

然而在真實業(yè)務(wù)中，寫出一個好測試的難度并不低。我總結(jié)了一下寫測試的幾個難點：

不會配置。 Jest 的上手文檔非常簡單，甚至不需要配置。但真實情況是只要一個配置沒配好，所有測試都跑不起來。測試不像開發(fā)，代碼有問題可以慢慢調(diào)， 而是一個 0 - 1 游戲，不是成功就是失敗，挫敗感非常強。

不知道要怎么 Mock。 這個絕對是經(jīng)典中的經(jīng)典。雖然官方文檔有教程，但是真實的業(yè)務(wù)往往不是那么理想，遠比文檔要復雜得多。

不會構(gòu)造測試用例。 剛接觸測試時，很容易把做業(yè)務(wù)那套 “實現(xiàn) XXX 功能” 的想法代入測試。但測試的重點不在于實現(xiàn)功能，而是構(gòu)造用例。

沒有測試策略。 上面是 “技” 的難點，測試還有 “術(shù)” 的難點。悶著頭肝測試并不高效，使用合適的測試策略遠比寫 10 個測試用例重要。

上面這些問題很容易讓人寫出難以維護和復雜的測試。只要業(yè)務(wù)一改，不僅要維護業(yè)務(wù)代碼還要維護測試代碼。這時，你不禁感嘆：“測試真浪費時間”，最終放棄寫測試，直接開擺。

好的測試會讓你獲得很高的代碼信心，而不好的測試則會嚴重拖垮項目開發(fā)。所以，大家所厭惡的不應該是測試本身，而是那些維護性差的測試。

社區(qū)現(xiàn)狀

目前國內(nèi)關(guān)于前端測試的內(nèi)容非常糟糕，在我查找資料過程中就沒有一次是不坎坷的。首先是 Jest 的官網(wǎng)就不給力：

先不說翻譯的正確性如何，單看這中文的內(nèi)容就讓人沒有想看下去的欲望，真希望 Jest 能找稍微專業(yè)一點的人來做翻譯。由于官網(wǎng)的中文翻譯做的實在太爛，遇到問題幾乎在中文社區(qū)是找不到的。

再來說國內(nèi)關(guān)于測試的文章，我總結(jié)有三類：

1. 入門類。 安裝 Jest，外加 expect(1 + 1).toEqual(2) 小例子
2. API 說明書類。 類似于把 Jest 官網(wǎng)抄了一遍
3. 理論類。 詳細說了測試是什么、為什么、測試理論等，但最重要的 “怎么做” 沒有說

不是說這些文章不好，只是這些文章大多數(shù)停留在最初級，看完還是不會怎么寫測試。就現(xiàn)狀來看國內(nèi)測試社區(qū)是有進步的，至少有不少人在寫第三類了，要知道以前基本只有第一類文章。

教程誕生

終于，我看到了 React Testing Library 作者 Kent C. Dodds 的 博客 。

他寫了很多關(guān)于測試思路的文章，每一篇都非常精彩。受他的啟發(fā)，我覺得有必要把這些思想和技巧分享出來，最終形成了這本小書。這本小書要解決的就是 “怎么做” 這一步。

內(nèi)容

此次教程主要分享測試的思路為主，雖然以 React 為主要技術(shù)棧，但使用其它技術(shù)棧的讀者依然可以流暢閱讀。

本教程是我結(jié)合了自身實踐、Kent C. Dodds 文章、StackOverflow、Github Issue 以及別的博客最終總結(jié)出來的一套實踐指南。

小書包含 3 部分：

• 基礎(chǔ)實踐。 從 0 到 1 寫項目和測試，每一章會通過一個業(yè)務(wù)例子來分享測試難點、解法和思路。
• 配套項目。 如果你在某一步卡殼了，也可以參考這個項目。
• 測試思路。 分享一些 Kent 的文章（中文翻譯）以及測試總結(jié)。

最后

我知道很多人看到這個貼子依然對測試嗤之以鼻，可能覺得寫測試就是扯淡、浪費時間的，也可能你已經(jīng)對國內(nèi)的 “短平快” 失望了，這個我完全能理解。

但我相信總有人愿意寫測試的，我希望在他們學習如何寫測試時能給一個方向和引導。

如果你喜歡我的分享，可以來一波一鍵三連，點贊、在看就是我最大的動力，比心 ??

參考資料