摘要：寫好的單元測試，對開發(fā)速度項目維護有莫大的幫助。我認(rèn)為單元測試的上下文存在于敏捷中。接下來一小節(jié)，就可以正式進入如何做的環(huán)節(jié)了如何寫好單元測試。前面說到，我們對單元測試寄予

寫好的單元測試，對開發(fā)速度、項目維護有莫大的幫助。前端的測試工具一直推陳出新，而測試的核心、原則卻少有變化。與產(chǎn)品代碼一并交付可靠的測試代碼，是每個專業(yè)開發(fā)者應(yīng)該不斷靠近的一個理想之地。本文就圍繞測試講講，為什么我們要做測試，什么是好的測試和原則，以及如何在一個 React 項目中落地這些測試策略。

本文使用的測試框架、斷言工具是 jest。文章不打算對測試框架、語法本身做過多介紹，因為已有很多文章。本文假定讀者已有一定基礎(chǔ)，至少熟悉語法，但并不假設(shè)讀者寫過單元測試。在介紹什么是好的單元測試時，我會簡單介紹一個好的單元測試的結(jié)構(gòu)。
Github 討論：https://github.com/linesh-sim...
原文地址：https://blog.linesh.tw/#/post...

目錄

為什么要做單元測試

單元測試的上下文

測試策略：測試金字塔

如何寫好單元測試：好測試的特征

有且僅有一個失敗的理由

表達力極強

快、穩(wěn)定

React 單元測試策略及落地

React 應(yīng)用的單元測試策略

actions 測試

reducer 測試

selector 測試

saga 測試

來自官方的錯誤姿勢

正確姿勢

component 測試

業(yè)務(wù)型組件 - 分支渲染

業(yè)務(wù)型組件 - 事件調(diào)用

功能型組件 - children 型高階組件

utils 測試

總結(jié)

未盡話題 & 歡迎討論

為什么要做單元測試

雖然關(guān)于測試的文章有很多，關(guān)于 React 的文章也有很多，但關(guān)于 React 應(yīng)用之詳細單元測試的文章還比較少。而且更多的文章都更偏向于對工具本身進行講解，只講「我們可以這么測」，卻沒有回答「我們?yōu)槭裁匆@么測」、「這么測究竟好不好」的問題。這幾個問題上的空白，難免使人得出測試無用、測試成本高、測試使開發(fā)變慢的錯誤觀點，導(dǎo)致在「質(zhì)量內(nèi)建」已漸入人心的今日，很多人仍然認(rèn)為測試是二等公民，是成本，是錦上添花。這一點上，我的態(tài)度一貫鮮明：不僅要寫測試，還要把單元測試寫好；不僅要有測試前移質(zhì)量內(nèi)建的意識，還要有基于測試進行快速反饋快速開發(fā)的能力。沒自動化測試的代碼不叫完成，不能驗收。

「為什么我們需要做單元測試」，這是一個關(guān)鍵的問題。每個人都有自己關(guān)于該不該做測試、該怎么做、做到什么程度的看法，試圖面面俱到、左右逢源地評價這些看法是不可能的。我們需要一個視角，一個談?wù)搯卧獪y試的上下文。做單元測試當(dāng)然有好處，但本文不會從有什么好處出發(fā)來談，而是談，在我們在意的這個上下文中，不做單元測試會有什么問題。

那么我們談?wù)搯卧獪y試的上下文是什么呢？不做單元測試我們會遇到什么問題呢？

單元測試的上下文

先說說問題。最大的一個問題是，不寫單元測試，你就不敢重構(gòu)，就只能看著代碼腐化。代碼質(zhì)量談不上，持續(xù)改進談不上，個人成長更談不上。始終是原始的勞作方式。

再說說上下文。我認(rèn)為單元測試的上下文存在于「敏捷」中。現(xiàn)代企業(yè)數(shù)字化競爭日益激烈，業(yè)務(wù)端快速上線、快速驗證、快速失敗的思路對技術(shù)端的響應(yīng)力提出了更高的要求：更快上線、更頻繁上線、持續(xù)上線。怎么樣衡量這個「更快」呢？那就是第一圖提到的 lead time，它度量的是一個 idea 從提出并被驗證，到最終上生產(chǎn)環(huán)境面對用戶獲取反饋的時間。顯然，這個時間越短，軟件就能越快獲得反饋，對價值的驗證就越快發(fā)生。這個結(jié)論對我們寫不寫單元測試有什么影響呢？答案是，不寫單元測試，你就快不起來。為啥呢？因為每次發(fā)布，你都要投入人力來進行手工測試；因為沒有測試，你傾向于不敢隨意重構(gòu)，這又導(dǎo)致代碼逐漸腐化，復(fù)雜度使得你的開發(fā)速度降低。

再考慮到以下兩個大事實：人員會流動，應(yīng)用會變大。人員一定會流動，需求一定會增加，再也沒有任何人能夠了解任何一個應(yīng)用場景。因此，意圖依賴人、依賴手工的方式來應(yīng)對響應(yīng)力的挑戰(zhàn)首先是低效的，從時間維度上來講也是不現(xiàn)實的。那么，為了服務(wù)于「高響應(yīng)力」這個目標(biāo)，我們就需要一套自動化的測試套件，它能幫我們提供快速反饋、做質(zhì)量的守衛(wèi)者。唯解決了人工、質(zhì)量的這一環(huán)，效率才能穩(wěn)步提升，團隊和企業(yè)的高響應(yīng)力才可能達到。

那么在「響應(yīng)力」這個上下文中來談要不要單元測試，我們就可以很有根據(jù)了，而不是開發(fā)爽了就用，不爽就不用這樣含糊的答案：

如果你說我的業(yè)務(wù)部門不需要頻繁上線，并且我有足夠的人力來覆蓋手工測試，那你可以不用單元測試

如果你說我是個小項目小部門不需要多高的響應(yīng)力，每天摸摸魚就過去了，那你可以不用單元測試

如果你說我不在意代碼腐化，并且我也不做重構(gòu)，那你可以不用單元測試

如果你說我不在意代碼質(zhì)量，好幾個沒有測試保護的 if-else 裸奔也不在話下，腦不好還做什么程序員，那你可以不用單元測試

如果你說我確有快速部署的需求，但我們不 care 質(zhì)量問題，出回歸問題就修，那你可以不用單元測試

除此之外，你就需要寫單元測試。如果你想隨時整理重構(gòu)代碼，那么你需要寫單元測試；如果你想有自動化的測試套件來幫你快速驗證提交的完整性，那么你需要寫單元測試；如果你是個長期項目有人員流動，那么你需要寫單元測試；如果你不想花大量的時間在記住業(yè)務(wù)場景和手動測試應(yīng)用上，那么你就需要單元測試。

至此，我們從「響應(yīng)力」這個上下文中，回答了「為什么我們需要寫單元測試」的問題。接下來可以談下一個問題了：「為什么是單元測試」。

測試策略：測試金字塔

上面我直接從高響應(yīng)力談到單元測試，可能有的同學(xué)會問，高響應(yīng)力這個事情我認(rèn)可，也認(rèn)可快速開發(fā)的同時，質(zhì)量也很重要。但是，為了達到「保障質(zhì)量」的目的，不一定得通過測試呀，也不一定得通過單元測試鴨。

這是個好的問題。為了達到保障質(zhì)量這個目標(biāo)，測試當(dāng)然只是其中一個方式，穩(wěn)定的自動化部署、集成流水線、良好的代碼架構(gòu)、組織架構(gòu)的必要調(diào)整等，都是必須跟上的設(shè)施。我從未認(rèn)為單元測試是解決質(zhì)量問題的銀彈，多方共同提升才可能起到效果。但相反，也很難想象單元測試都沒有都寫不好的項目，能有多高的響應(yīng)力。

即便我們談自動化測試，未必也不可能全部都是寫單元測試。我們對自動化測試套件寄予的厚望是，它能幫我們安全重構(gòu)已有代碼、保存業(yè)務(wù)上下文、快速回歸。測試種類多種多樣，為什么我要重點談單元測試呢？因為這篇文章主題就是談單元測試啊…它寫起來相對最容易、運行速度最快、反饋效果又最直接。下面這個圖，想必大家都有所耳聞：

這就是有名的測試金字塔。對于一個自動化測試套件，應(yīng)該包含種類不同、關(guān)注點不同的測試，比如關(guān)注單元的單元測試、關(guān)注集成和契約的集成測試和契約測試、關(guān)注業(yè)務(wù)驗收點的端到端測試等。正常來說，我們會受到資源的限制，無法應(yīng)用所有層級的測試，效果也未必最佳。因此，我們需要有策略性地根據(jù)收益-成本的原則，考慮項目的實際情況和痛點來定制測試策略：比如三方依賴多的項目可以多寫些契約測試，業(yè)務(wù)場景多、復(fù)雜或經(jīng)常回歸的場景可以多寫些端到端測試，等。但不論如何，整個測試金字塔體系中，你還是應(yīng)該擁有更多低層次的單元測試，因為它們成本相對最低，運行速度最快（通常是毫秒級別），而對單元的保護價值相對更大。

以上是對「為什么我們需要的是單元測試」這個問題的回答。接下來一小節(jié)，就可以正式進入如何做的環(huán)節(jié)了：「如何寫好單元測試」。

關(guān)于測試金字塔的補充閱讀：測試金字塔實戰(zhàn)。

如何寫好單元測試：好測試的特征

寫單元測試僅僅是第一步，下面還有個更關(guān)鍵的問題，就是怎樣寫出好的、容易維護的單元測試。好的測試有其特征，雖然它并不是什么新的東西，但總需要時時拿出來溫故知新。很多時候，同學(xué)感覺測試難寫、難維護、不穩(wěn)定、價值不大等，可能都是因為單元測試寫不好所導(dǎo)致的。那么我們就來看看，一個好的單元測試，應(yīng)該遵循哪幾點原則。

首先，我們先來看個簡單的例子，一個最簡單的 JavaScript 的單元測試長什么樣：

// production code
const computeSumFromObject = (a, b) => {
  return a.value + b.value
}

// testing code
it("should return 5 when adding object a with value 2 and b with value 3", () => {
  // given - 準(zhǔn)備數(shù)據(jù)
  const a = { value: 2 }
  const b = { value: 3 }

  // when - 調(diào)用被測函數(shù)
  const result = computeSumFromObject(a, b)

  // then - 斷言結(jié)果
  expect(result).toBe(5)
})

以上就是一個最簡答的單元測試部分。但麻雀雖小，五臟基本全，它揭示了單元測試的一個基本結(jié)構(gòu)：準(zhǔn)備輸入數(shù)據(jù)、調(diào)用被測函數(shù)、斷言輸出結(jié)果。任何單元測試都可以遵循這樣一個骨架，它是我們常說的 given-when-then 三段式。

為什么說單元測試說來簡單，做到卻不簡單呢？除了遵循三段式，顯然我們還需要遵循一些其他的原則。前面說到，我們對單元測試寄予了幾點厚望，下面就來看看，它如何能達到我們期望的效果，以此來反推單元測試的特征：

安全重構(gòu)已有代碼 -> 應(yīng)該有且僅有一個失敗的理由、不關(guān)注內(nèi)部實現(xiàn)

保存業(yè)務(wù)上下文 -> 表達力極強

快速回歸 -> 快、穩(wěn)定

下面來看看這三個原則都是咋回事：

有且僅有一個失敗的理由

有且僅有一個失敗的理由，這個理由是什么呢？是 「當(dāng)輸入不變時，當(dāng)且僅當(dāng)被測業(yè)務(wù)代碼功能被改動了」時，測試才應(yīng)該掛掉。為什么這會支持我們重構(gòu)呢，因為重構(gòu)的意思是，在不改動軟件外部可觀測行為的基礎(chǔ)上，調(diào)整軟件內(nèi)部實現(xiàn)的一種手段。也就是說，當(dāng)我被測的代碼輸入輸出沒變時，任我怎么倒騰重構(gòu)代碼的內(nèi)部實現(xiàn)，測試都不應(yīng)該掛掉。這樣才能說是支持了重構(gòu)。有的單元測試寫得，內(nèi)部實現(xiàn)（比如數(shù)據(jù)結(jié)構(gòu)）一調(diào)整，測試就掛掉，盡管它的業(yè)務(wù)本身并沒修改，這樣怎么支持重構(gòu)呢？不怪得要反過來罵測試成本高，沒有用。一般會出現(xiàn)這種情況，可能是因為是先寫完代碼再補的測試，或者對代碼的接口和抽象不明確所導(dǎo)致。

另外，還有一些測試（比如下文要看到的 saga 官方推薦的測試），它需要測試實現(xiàn)代碼的執(zhí)行次序。這也是一種「關(guān)注內(nèi)部實現(xiàn)」的測試，這就使得除了業(yè)務(wù)目標(biāo)外，還有「執(zhí)行次序」這個因素可能使測試掛掉。這樣的測試也是很脆弱的。

表達力極強

表達力極強，講的是兩方面：

看到測試時，你就知道它測的業(yè)務(wù)點是啥

測試掛掉時，能清楚地知道業(yè)務(wù)、期望數(shù)據(jù)與實際輸出的差異

這些表達力體現(xiàn)在許多方面，比如測試描述、數(shù)據(jù)準(zhǔn)備的命名、與測試無關(guān)數(shù)據(jù)的清除、斷言工具能提供的比對等。空口無憑，請大家在閱讀后面測試落地時時常對照。

快、穩(wěn)定

不快的單元測試還能叫單元測試嗎？一般來講，一個沒有依賴、沒有 API 調(diào)用的單元測試，都能在毫秒級內(nèi)完成。那么為了達到快、穩(wěn)定這個目標(biāo)，我們需要：

隔離盡量多的依賴。依賴少，速度就快，自然也更穩(wěn)定

將依賴、集成等耗時、依賴三方返回的地方放到更高層級的測試中，有策略性地去做

測試代碼中不要包含邏輯。不然你咋知道是實現(xiàn)掛了還是你的測試掛了呢？

在后面的介紹中，我會將這些原則落實到我們寫的每個單元測試中去。大家可以時時翻到這個章節(jié)來對照，是不是遵循了我們說的這幾點原則，不遵循是不是確實會帶來問題。時時勤拂拭，莫使惹塵埃啊。

React 單元測試策略及落地

React 應(yīng)用的單元測試策略

上個項目上的 React(-Native) 應(yīng)用架構(gòu)如上所述。它涉及一個常見 React 應(yīng)用的幾個層面：組件、數(shù)據(jù)管理、redux、副作用管理等，是一個常見的 React、Redux 應(yīng)用架構(gòu)，也是 dva 所推薦的 66%的最佳實踐（redux+saga），對于不同的項目應(yīng)該有一定的適應(yīng)性。架構(gòu)中的不同元素有不同的特點，因此即便是單元測試，我們也有針對性的測試策略：

架構(gòu)層級	測試內(nèi)容	測試策略	解釋
action(creator) 層	是否正確創(chuàng)建 action 對象	一般不需要測試，視信心而定	這個層級非常簡單，基礎(chǔ)設(shè)施搭好以后一般不可能出錯，享受了架構(gòu)帶來的簡單性
reducer 層	是否正確完成計算	對于有邏輯的 reducer 需要 100%覆蓋率	這個層級輸入輸出明確，又有業(yè)務(wù)邏輯的計算在內(nèi)，天然屬于單元測試寵愛的對象
selector 層	是否正確完成計算	對于有較復(fù)雜邏輯的 selector 需要 100%覆蓋率	這個層級輸入輸出明確，又有業(yè)務(wù)邏輯的計算在內(nèi)，天然屬于單元測試寵愛的對象
saga(副作用) 層	是否獲取了正確的參數(shù)去調(diào)用 API，并使用正確的數(shù)據(jù)存取回 redux 中	對于是否獲取了正確參數(shù)、是否調(diào)用正確的 API、是否使用了正確的返回值保存數(shù)據(jù)、業(yè)務(wù)分支邏輯、異常分支 這五個業(yè)務(wù)點建議 100% 覆蓋	這個層級也有業(yè)務(wù)邏輯，對前面所述的 5 大方面進行測試很有重構(gòu)價值
component(組件接入) 層	是否渲染了正確的組件	組件的分支渲染邏輯要求 100% 覆蓋、交互事件的調(diào)用參數(shù)一般要求 100% 覆蓋、被 redux connect 過的組件不測、純 UI 不測、CSS 一般不測	這個層級最為復(fù)雜，測試策略還是以「代價最低，收益最高」為指導(dǎo)原則進行
UI 層	樣式是否正確	目前不測	這個層級以我目前理解來說，測試較難穩(wěn)定，成本又較高
utils 層	各種幫助函數(shù)	沒有副作用的必須 100% 覆蓋，有副作用的視項目情況自定

對于這個策略，這里做一些其他補充：

關(guān)于不測 redux connect 過的組件這個策略。理由是成本遠高于收益：要犧牲開發(fā)體驗（搞起來沒那么快了），要配置依賴（配置 store、 ，在大型或遺留系統(tǒng)中補測試還很可能遇到 @connect 組件里套 @connect 組件的場景）；然后收益也只是可能覆蓋到了幾個極少數(shù)出現(xiàn)的場景。得不償失，果斷不測。

關(guān)于 UI 測試這塊的策略。團隊之前嘗試過 snapshot 測試，對它寄予厚望，理由是成本低，看起來又像萬能藥。不過由于其難以提供精確快照比對，整個工作的基礎(chǔ)又依賴于開發(fā)者盡心做好「確認(rèn)比對」這個事情，很依賴人工耐心又打斷日常的開發(fā)節(jié)奏，導(dǎo)致成本和收益不成正比。我個人目前是持保留態(tài)度的。

關(guān)于 DOM 測試這塊的策略。也就是通過 enzyme 這類工具，通過 css selector 來進行 DOM 渲染方面的測試。這類測試由于天生需要通過 css selector 去關(guān)聯(lián) DOM 元素，除了被測業(yè)務(wù)外 css selector 本身就是掛測試的一個因素。一個 DOM 測試至少有兩個原因可使它掛掉，并不符合我們上面提到的最佳實踐。但這種測試有時又確實有用，后文講組件測試時會專門提到，如何針對它制定適合的策略。

actions 測試

這一層太過簡單，基本都可以不用測試，獲益于架構(gòu)的簡單性。當(dāng)然，如果有些經(jīng)常出錯的 action，再針對性地對這些 action creator 補充測試。

export const saveUserComments = (comments) => ({
  type: "saveUserComments",
  payload: {
    comments,
  },
})

import * as actions from "./actions"

test("should dispatch saveUserComments action with fetched user comments", () => {
  const comments = []
  const expected = {
    type: "saveUserComments",
    payload: {
      comments: [],
    },
  }

  expect(actions.saveUserComments(comments)).toEqual(expected)
})

reducer 測試

reducer 大概有兩種：一種比較簡單，僅一一保存對應(yīng)的數(shù)據(jù)切片；一種復(fù)雜一些，里面具有一些計算邏輯。對于第一種 reducer，寫起來非常簡單，簡單到甚至可以不需要用測試去覆蓋。其正確性基本由簡單的架構(gòu)和邏輯去保證的。下面是對一個簡單 reducer 做測試的例子：

import Immutable from "seamless-immutable"

const initialState = Immutable.from({
  isLoadingProducts: false,
})

export default createReducer((on) => {
  on(actions.isLoadingProducts, (state, action) => {
    return state.merge({
      isLoadingProducts: action.payload.isLoadingProducts,
    })
  })
}, initialState)

import reducers from "./reducers"
import actions from "./actions"

test("should save loading start indicator when action isLoadingProducts is dispatched given isLoadingProducts is true", () => {
  const state = { isLoadingProducts: false }
  const expected = { isLoadingProducts: true }

  const result = reducers(state, actions.isLoadingProducts(true))

  expect(result).toEqual(expected)
})

下面是一個較為復(fù)雜、更具備測試價值的 reducer 例子，它在保存數(shù)據(jù)的同時，還進行了合并、去重的操作：

import uniqBy from "lodash/uniqBy"

export default createReducers((on) => {
  on(actions.saveUserComments, (state, action) => {
    return state.merge({
      comments: uniqBy(
        state.comments.concat(action.payload.comments), 
        "id",
      ),
    })
  })
})

import reducers from "./reducers"
import actions from "./actions"

test(`
  should merge user comments and remove duplicated comments 
  when action saveUserComments is dispatched with new fetched comments
`, () => {
  const state = {
    comments: [{ id: 1, content: "comments-1" }],
  }
  const comments = [
    { id: 1, content: "comments-1" },
    { id: 2, content: "comments-2" },
  ]

  const expected = {
    comments: [
      { id: 1, content: "comments-1" },
      { id: 2, content: "comments-2" },
    ],
  }

  const result = reducers(state, actions.saveUserComments(comments))

  expect(result).toEqual(expected)
})

reducer 作為純函數(shù)，非常適合做單元測試，加之一般在 reducer 中做重邏輯處理，此處做單元測試保護的價值也很大。請留意，上面所說的單元測試，是不是符合我們描述的單元測試基本原則：

有且僅有一個失敗的理由：當(dāng)輸入不變時，僅當(dāng)我們被測「合并去重」的業(yè)務(wù)操作不符預(yù)期時，才可能掛掉測試

表達力極強：測試描述已經(jīng)寫得清楚「當(dāng)使用新獲取到的留言數(shù)據(jù)分發(fā) action saveUserComments 時，應(yīng)該與已有留言合并并去除重復(fù)的部分」；此外，測試數(shù)據(jù)只準(zhǔn)備了足夠體現(xiàn)「合并」這個操作的兩條 id 的數(shù)據(jù)，而沒有放很多的數(shù)據(jù)，形成雜音；

快、穩(wěn)定：沒有任何依賴，測試代碼不包含準(zhǔn)備數(shù)據(jù)、調(diào)用、斷言外的任何邏輯

selector 測試

selector 同樣是重邏輯的地方，可以認(rèn)為是 reducer 到組件的延伸。它也是一個純函數(shù)，測起來與 reducer 一樣方便、價值不菲，也是應(yīng)該重點照顧的部分。況且，稍微大型一點的項目，應(yīng)該說必然會用到 selector。原因我講在這里。下面看一個 selector 的測試用例：

import { createSelector } from "reselect"

// for performant access/filtering in React component
export const labelArrayToObjectSelector = createSelector(
  [(store, ownProps) => store.products[ownProps.id].labels],
  (labels) => {
    return labels.reduce(
      (result, { code, active }) => ({
        ...result,
        [code]: active,
      }),
      {}
    )
  }
)

import { labelArrayToObjectSelector } from "./selector"

test("should transform label array to object", () => {
  const store = {
    products: {
      10085: {
        labels: [
          { code: "canvas", name: "帆布鞋", active: false },
          { code: "casual", name: "休閑鞋", active: false },
          { code: "oxford", name: "牛津鞋", active: false },
          { code: "bullock", name: "布洛克", active: true },
          { code: "ankle", name: "高幫鞋", active: true },
        ],
      },
    },
  }
  const expected = {
    canvas: false,
    casual: false,
    oxford: false,
    bullock: true,
    ankle: false,
  }

  const productLabels = labelArrayToObjectSelector(store, { id: 10085 })

  expect(productLabels).toEqual(expected)
})

saga 測試

saga 是負(fù)責(zé)調(diào)用 API、處理副作用的一層。在實際的項目上副作用還有其他的中間層進行處理，比如 redux-thunk、redux-promise 等，本質(zhì)是一樣的，只不過 saga 在測試性上要好一些。這一層副作用怎么測試呢？首先為了保證單元測試的速度和穩(wěn)定性，像 API 調(diào)用這種不確定性的依賴我們一定是要 mock 掉的。經(jīng)過仔細總結(jié)，我認(rèn)為這一層主要的測試內(nèi)容有五點：

是否使用正確的參數(shù)（通常是從 action payload 或 redux 中來），調(diào)用了正確的 API

對于 mock 的 API 返回，是否保存了正確的數(shù)據(jù)（通常是通過 action 保存到 redux 中去）

主要的業(yè)務(wù)邏輯（比如僅當(dāng)用戶滿足某些權(quán)限時才調(diào)用 API 等）

異常邏輯

其他副作用是否發(fā)生（比如有時有需要 Emit 的事件、需要保存到 IndexDB 中去的數(shù)據(jù)等）

來自官方的錯誤姿勢

redux-saga 官方提供了一個 util: CloneableGenerator 用以幫我們寫 saga 的測試。這是我們項目使用的第一種測法，大概會寫出來的測試如下：

import chunk from "lodash/chunk"

export function* onEnterProductDetailPage(action) {
  yield put(actions.notImportantAction1("loading-stuff"))
  yield put(actions.notImportantAction2("analytics-stuff"))
  yield put(actions.notImportantAction3("http-stuff"))
  yield put(actions.notImportantAction4("other-stuff"))

  const recommendations = yield call(Api.get, "products/recommended")
  const MAX_RECOMMENDATIONS = 3
  const [products = []] = chunk(recommendations, MAX_RECOMMENDATIONS)

  yield put(actions.importantActionToSaveRecommendedProducts(products))

  const { payload: { userId } } = action
  const { vipList } = yield select((store) => store.credentails)
  if (!vipList.includes(userId)) {
    yield put(actions.importantActionToFetchAds())
  }
}

import { put, call } from "saga-effects"
import { cloneableGenerator } from "redux-saga/utils"
import { Api } from "src/utils/axios"
import { onEnterProductDetailPage } from "./saga"

const product = (productId) => ({ productId })

test(`
  should only save the three recommended products and show ads 
  when user enters the product detail page 
  given the user is not a VIP
`, () => {
  const action = { payload: { userId: 233 } }
  const credentials = { vipList: [2333] }
  const recommendedProducts = [product(1), product(2), product(3), product(4)]
  const firstThreeRecommendations = [product(1), product(2), product(3)]
  const generator = cloneableGenerator(onEnterProductDetailPage)(action)

  expect(generator.next().value).toEqual(
    actions.notImportantAction1("loading-stuff")
  )
  expect(generator.next().value).toEqual(
    actions.notImportantAction2("analytics-stuff")
  )
  expect(generator.next().value).toEqual(
    actions.notImportantAction3("http-stuff")
  )
  expect(generator.next().value).toEqual(
    actions.notImportantAction4("other-stuff")
  )

  expect(generator.next().value).toEqual(call(Api.get, "products/recommended"))
  expect(generator.next(recommendedProducts).value).toEqual(
    firstThreeRecommendations
  )
  generator.next()
  expect(generator.next(credentials).value).toEqual(
    put(actions.importantActionToFetchAds())
  )
})

這個方案寫多了，大家開始感受到了痛點，明顯違背我們前面提到的一些原則：

測試分明就是把實現(xiàn)抄了一遍。這違反上述所說「有且僅有一個掛測試的理由」的原則，改變實現(xiàn)次序也將會使測試掛掉

當(dāng)在實現(xiàn)中某個部分加入新的語句時，該語句后續(xù)所有的測試都會掛掉，并且出錯信息非常難以描述原因，導(dǎo)致常常要陷入「調(diào)試測試」的境地，這也是依賴于實現(xiàn)次序帶來的惡果，根本無法支持「重構(gòu)」這種改變內(nèi)部實現(xiàn)但不改變業(yè)務(wù)行為的代碼清理行為

為了測試兩個重要的業(yè)務(wù)「只保存獲取回來的前三個推薦產(chǎn)品」、「對非 VIP 用戶推送廣告」，不得不在前面先按次序先斷言許多個不重要的實現(xiàn)

測試沒有重點，隨便改點什么都會掛測試

正確姿勢

針對以上痛點，我們理想中的 saga 測試應(yīng)該是這樣：1) 不依賴實現(xiàn)次序；2) 允許僅對真正關(guān)心的、有價值的業(yè)務(wù)進行測試；3) 支持不改動業(yè)務(wù)行為的重構(gòu)。如此一來，測試的保障效率和開發(fā)者體驗都將大幅提升。

于是，我們發(fā)現(xiàn)官方提供了這么一個跑測試的工具，剛好可以用來完美滿足我們的需求：runSaga。我們可以用它將 saga 全部執(zhí)行一遍，搜集所有發(fā)布出去的 action，由開發(fā)者自由斷言其感興趣的 action！基于這個發(fā)現(xiàn)，我們推出了我們的第二版 saga 測試方案：runSaga + 自定義拓展 jest 的 expect 斷言。最終，使用這個工具寫出來的 saga 測試，幾近完美：

import { put, call } from "saga-effects"
import { Api } from "src/utils/axios"
import { testSaga } from "../../../testing-utils"
import { onEnterProductDetailPage } from "./saga"

const product = (productId) => ({ productId })

test(`
  should only save the three recommended products and show ads 
  when user enters the product detail page 
  given the user is not a VIP
`, async () => {
  const action = { payload: { userId: 233 } }
  const store = { credentials: { vipList: [2333] } }
  const recommendedProducts = [product(1), product(2), product(3), product(4)]
  const firstThreeRecommendations = [product(1), product(2), product(3)]
  Api.get = jest.fn().mockImplementations(() => recommendedProducts)

  await testSaga(onEnterProductDetailPage, action, store)

  expect(Api.get).toHaveBeenCalledWith("products/recommended")
  expect(
    actions.importantActionToSaveRecommendedProducts
  ).toHaveBeenDispatchedWith(firstThreeRecommendations)
  expect(actions.importantActionToFetchAds).toHaveBeenDispatched()
})

這個測試已經(jīng)簡短了許多，沒有了無關(guān)斷言的雜音，依然遵循 given-when-then 的結(jié)構(gòu)。并且同樣是測試「只保存獲取回來的前三個推薦產(chǎn)品」、「對非 VIP 用戶推送廣告」兩個關(guān)心的業(yè)務(wù)點，其中自有簡潔的規(guī)律：

當(dāng)輸入不變時，無論你怎么優(yōu)化內(nèi)部實現(xiàn)、調(diào)整內(nèi)部次序，這個測試關(guān)心的業(yè)務(wù)場景都不會掛，真正做到了測試保護重構(gòu)、支持重構(gòu)的作用

可以僅斷言你關(guān)心的點，忽略不重要或不關(guān)心的中間過程（比如上例中，我們就沒有斷言其他 notImportant 的 action 是否被 dispatch 出去），消除無關(guān)斷言的雜音，提升了表達力

使用了 product 這樣的測試數(shù)據(jù)創(chuàng)建套件（fixtures），精簡測試數(shù)據(jù)，消除無關(guān)數(shù)據(jù)的雜音，提升了表達力

自定義的 expect(action).toHaveBeenDispatchedWith(payload) matcher 很有表達力，且出錯信息友好

這個自定義的 matcher 是通過 jest 的 expect.extend 擴展實現(xiàn)的：

expect.extend({
  toHaveBeenDispatched(action) { ... },
  toHaveBeenDispatchedWith(action, payload) { ... },
})

上面是我們認(rèn)為比較好的副作用測試工具、測試策略和測試方案。使用時，需要牢記你真正關(guān)心的業(yè)務(wù)價值點（本節(jié)開始提到的 5 點），以及做到在較為復(fù)雜的單元測試中始終堅守三大基本原則。唯如此，單元測試才能真正提升開發(fā)速度、支持重構(gòu)、充當(dāng)業(yè)務(wù)上下文的文檔。

component 測試

組件測試其實是實踐最多，測試實踐看法和分歧也最多的地方。React 組件是一個高度自治的單元，從分類上來看，它大概有這么幾類：

展示型業(yè)務(wù)組件

容器型業(yè)務(wù)組件

通用 UI 組件

功能型組件

先把這個分類放在這里，待會回過頭來談。對于 React 組件測什么不測什么，我有一些思考，也有一些判斷標(biāo)準(zhǔn)：除去功能型組件，其他類型的組件一般是以渲染出一個語法樹為終點的，它描述了頁面的 UI 內(nèi)容、結(jié)構(gòu)、樣式和一些邏輯 component(props) => UI。內(nèi)容、結(jié)構(gòu)和樣式，比起測試，直接在頁面上調(diào)試反饋效果更好。測也不是不行，但都難免有不穩(wěn)定的成本在；邏輯這塊，還是有一測的價值，但需要控制好依賴。綜合「好的單元測試標(biāo)準(zhǔn)」作為原則進行考慮，我的建議是：兩測兩不測。

組件分支渲染邏輯必須測

事件調(diào)用和參數(shù)傳遞一般要測

純 UI 不在單元測試層級測

連接 redux 的高階組件不測

其他的一般不測（比如 CSS，官方文檔有反例）

組件的分支邏輯，往往也是有業(yè)務(wù)含義和業(yè)務(wù)價值的分支，添加單元測試既能保障重構(gòu)，還可順便做文檔用；事件調(diào)用同樣也有業(yè)務(wù)價值和文檔作用，而事件調(diào)用的參數(shù)調(diào)用有時可起到保護重構(gòu)的作用。

純 UI 不在單元測試級別測試的原因，純粹就是因為不好斷言。所謂快照測試有意義的前提在于兩個：必須是視覺級別的比對、必須開發(fā)者每次都認(rèn)真檢查。jest 有個 snapshot 測試的概念，但那個 UI 測試是代碼級的比對，不是視覺級的比對，最終還是繞了一圈，去除了雜音還不如看 Git 的 commit diff。每次要求開發(fā)者自覺檢查，既打亂工作流，也難以堅持。考慮到這些成本，我不推薦在單元測試的級別來做 UI 類型的測試。對于我們之前中等規(guī)模的項目，訴諸手工還是有一定的可控性。

連接 redux 的高階組件不測。原因是，connect 過的組件從測試的角度看無非幾個測試點：

mapStateToProps 中是否從 store 中取得了正確的參數(shù)

mapDispatchToProps 中是否地從 actions 中取得了正確的參數(shù)

map 過的 props 是否正確地被傳遞給了組件

redux 對應(yīng)的數(shù)據(jù)切片更新時，是否會使用新的 props 觸發(fā)組件進行一次更新

這四個點，react-redux 已經(jīng)都幫你測過了，已經(jīng)證明 work 了，為啥要重復(fù)測試自尋煩惱呢？當(dāng)然，不測這個東西的話，還是有這么一種可能，就是你 export 的純組件測試都是過的，但是代碼實際運行出錯。窮盡下來主要可能是這幾種問題：

你在 mapStateToProps 中打錯了字或打錯了變量名

你寫了 mapStateToProps 但沒有 connect 上去

你在 mapStateToProps 中取的路徑是錯的，在 redux 中已經(jīng)被改過

第一、二種可能，無視。測試不是萬能藥，不能預(yù)防人主動犯錯，這種場景如果是小步提交發(fā)現(xiàn)起來是很快的，如果不小步提交那什么測試都幫不了你的；如果某段數(shù)據(jù)獲取的邏輯多處重復(fù)，則可以考慮將該邏輯抽取到 selector 中并進行多帶帶測試。

第三種可能，確實是問題，但發(fā)生頻率目前看來較低。為啥呢，因為沒有類型系統(tǒng)我們不會也不敢隨意改 redux 的數(shù)據(jù)結(jié)構(gòu)啊…（這侵入性重的框架喲）所以針對這些少量出現(xiàn)的場景，不必要采取錯殺一千的方式進行完全覆蓋。默認(rèn)不測，出了問題或者經(jīng)常可能出問題的部分，再策略性地補上測試進行固定即可。

綜上，@connect 組件不測，因為框架本身已做了大部分測試，剩下的場景出 bug 頻率不高，而施加測試的話提高成本（準(zhǔn)備依賴和數(shù)據(jù)），降低開發(fā)體驗，模糊測試場景，性價比不大，所以強烈建議省了這份心。不測 @connect 過的組件，其實也是 官方文檔 推薦的做法。

然后，基于上面第 1、2 個結(jié)論，映射回四類組件的結(jié)構(gòu)當(dāng)中去，我們可以得到下面的表格，然后發(fā)現(xiàn)…每種組件都要測渲染分支和事件調(diào)用，跟組件類型根本沒必然的關(guān)聯(lián)…不過，功能型組件有可能會涉及一些其他的模式，因此又大致分出一小節(jié)來談。

組件類型 / 測試內(nèi)容	分支渲染邏輯	事件調(diào)用	@connect	純 UI
展示型組件	?	?	-	??
容器型組件	?	?	??	??
通用 UI 組件	?	?	-	??
功能型組件	?	?	??	??

業(yè)務(wù)型組件 - 分支渲染

export const CommentsSection = ({ comments }) => (
  

    {comments.length > 0 && (
      
Comments
    )}

    {comments.map((comment) => (
      
    )}
  
)

對應(yīng)的測試如下，測試的是不同的分支渲染邏輯：沒有評論時，則不渲染 Comments header。

import { CommentsSection } from "./index"
import { Comment } from "./Comment"

test("should not render a header and any comment sections when there is no comments", () => {
  const component = shallow()

  const header = component.find("h2")
  const comments = component.find(Comment)

  expect(header).toHaveLength(0)
  expect(comments).toHaveLength(0)
})

test("should render a comments section and a header when there are comments", () => {
  const contents = [
    { id: 1, author: "男***8", comment: "價廉物美，相信奧康旗艦店" },
    { id: 2, author: "雨***成", comment: "所以一雙合腳的鞋子..." },
  ]
  const component = shallow()

  const header = component.find("h2")
  const comments = component.find(Comment)

  expect(header.html()).toBe("Comments")
  expect(comments).toHaveLength(2)
})

業(yè)務(wù)型組件 - 事件調(diào)用

測試事件的一個場景如下：當(dāng)某條產(chǎn)品被點擊時，應(yīng)該將產(chǎn)品相關(guān)的信息發(fā)送給埋點系統(tǒng)進行埋點。

export const ProductItem = ({
  id,
  productName,
  introduction,
  trackPressEvent,
}) => (
   trackPressEvent(id, productName)}>