圖片來自Craig Whitehead

幫助你確定測試內容的實用建議。

知道如何測試是很了不起的，也是非常重要的。我創建了很多內容，教人們測試的基礎知識，如何配置工具，如何為特定的場景編寫測試，等等。但是，知道如何編寫測試只是在你的應用程序中獲得信心的戰鬥的一半。知道要測試什麼是另一半非常重要的戰鬥。

在我的研討會資料(https://kentcdodds.com/workshops )和TestingJavaScript.com上，我確實談到了如何知道要測試什麼，但是我被問到這個問題已經夠多了，所以我覺得寫一篇關於它的博文可能會更好。就是這樣了!

記住我們為什麼要測試

我們編寫測試是為了確保當用戶使用我們的應用程序時它們能夠正常運行。有些人編寫測試是為了增強他們的工作流，這很好，但是我對增強信心更感興趣。既然如此，我們的測試就應該直接映射到增強我們的信心上。下面是我希望你在編寫測試時考慮的關鍵點:

少考慮你正在測試的代碼，多考慮代碼支持的用例。

當你考慮代碼本身時，開始測試實現細節就變得太容易也太自然了(但這將導致災難)。（https://kentcdodds.com/blog/testing-implementation-details ）

但是，考慮用例會讓我們以更接近於用戶使用應用程序的方式編寫測試:

你的測試與軟體的使用方式越相似，它們就能給你帶來越多的信心。——我的Twitter文（https://twitter.com/kentcdodds/status/977018512689455106 ）

代碼覆蓋率<用例覆蓋率

代碼覆蓋率是一個度量標準，它向我們顯示在測試期間正在運行的代碼行。我們以這段代碼為例:

目前，我們還沒有對這個函數進行測試，所以我們的代碼覆蓋率報告將表明我們對這個函數的覆蓋率為0%。這個用例中的代碼覆蓋率報告讓我們意識到測試是需要的,但它並沒有告訴我們這個函數的什麼地方是重要的,也沒有告訴我們這個函數支持哪些用例，這是我們在編寫測試時需要著重考慮的。

事實上，當我們考慮整個應用程序並想知道要測試什麼時，覆蓋率報告在幫助我們深入了解應該將大部分時間花在什麼地方這方面幾乎毫無幫助。

因此，覆蓋率報告只能幫助我們確定代碼庫中哪些代碼缺少測試。因此，當你在查看代碼覆蓋率報告並注意到缺少測試的代碼行時，不要考慮ifs/elses、循環或生命周期。相反,要問問自己:

這些代碼行支持哪些用例，我可以添加哪些測試來支持這些用例?

「用例覆蓋率」會告訴我們我們的測試支持多少用例。不幸的是，現在還沒有自動化的「用例覆蓋率報告」這樣的東西。我們得自己創建。但是代碼覆蓋報告有時可以幫助我們識別我們還沒有覆蓋的用例。我們來試一下它。

因此，如果我們閱讀代碼並思考一下，我們就可以確定要支持的第一個用例:「如果給定一個數組，它將返回一個數組。」這個用例語句實際上是我們的測試的一個很好的標題。

有了這個測試，我們的覆蓋率報告看起來像這樣(高亮顯示的行是被覆蓋的):

現在，我們來查看一下剩餘的行，並且可以確定還有兩個以上的用例我們的測試還不支持:

• 如果給定一個falsy(虛)值，它將返回一個空數組
• 如果它不是一個數組或falsy值，它將返回一個帶有給定參數的數組

我們來為這些用例添加測試，看看它如何影響代碼覆蓋率。

好了,差不多了!

太酷了!現在我們可以確信，只要我們不需要更改這個函數的用例，我們的測試就會繼續運行直到通過。

代碼覆蓋率並不是一個完美的度量標準，但是它可以作為一個有用的工具來確定代碼庫中哪些部分缺少「用例覆蓋率」。

代碼覆蓋可以隱藏用例

有時，我們的代碼覆蓋率報告會顯示100%的代碼覆蓋率，但並不是100%的用例覆蓋率。這就是為什麼有時我甚至會在開始編寫測試之前就試圖考慮所有的用例。

例如，我們假設arrayify函數是這樣實現的:

這樣，我們就可以通過以下兩個用例來獲得100%的覆蓋率:

• 如果給定一個數組，它將返回一個數組
• 如果不是數組，它將返回一個帶有給定參數的數組

但是如果我們能看一下用例覆蓋率報告，它會表明我們忽略了這個用例:

• 如果給定一個falsy值，它將返回一個空數組

這可能很糟糕，因為現在我們的測試沒有給我們足夠的信心，讓我們相信當用戶像這樣使用arrayify()時，我們的代碼能夠正常工作。現在，它很好，因為即使我們沒有對它進行測試，我們的代碼也支持那個用例。但是我們在適當的地方進行測試的原因是確保代碼繼續支持我們想要它支持的用例，即使事情發生了變化。

所以，我們舉個例子來說明遺漏這個測試是如何導致錯誤的，有人可能會過來，看到.filter(Boolean)之類的東西，然後想:「嗯，這太奇怪了……我懷疑我們是否真的需要它。」所以他們刪除了它，我們的測試繼續通過，但是任何依賴於錯誤行為的代碼現在都被破壞了。

關鍵要點: 測試用例，而不是代碼。

這如何應用於React?

在編寫代碼時，請記住你已經需要支持兩個用戶:最終用戶和開發人員用戶。同樣，如果你考慮的是代碼而不是用例，那麼開始測試實現細節就變得非常危險。當你這樣做時，你的代碼就有了第三個用戶。

下面是人們經常考慮的關於React測試的幾個方面，這些測試會導致實現細節測試。對於所有這些測試，與其考慮代碼，還不如考慮代碼對最終用戶和開發人員用戶的可見效果，那就是你的用例，測試它吧。

• 生命周期方法
• 元素事件處理程序
• 內部組件狀態

相反，你應該測試以下內容，因為它們涉及到你的兩個用戶。這些內容中的每一個都可以改變DOM，發出HTTP請求，調用prop回調函數，或者執行其他一些可觀察到的 附加作用，這些附加作用對測試非常有用:

• 用戶交互(使用來自react-testing-library的fireEvent):最終用戶是否能夠與組件渲染的元素交互?
• 改變prop(使用來自react-testing-library 的rerender):當開發人員用戶使用新的prop重新渲染組件時會發生什麼?
• 上下文更改(使用來自react-testing-library 的rerender):當開發人員用戶更改上下文導致組件重新渲染時會發生什麼?
• 訂閱更改:當組件訂閱的事件派發器改變時會發生什麼?(如firebase、redux商店、路由器、媒體查詢或基於DOM的訂閱，比如在線狀態)

我如何知道在一個app中從哪裡開始?

因此，我們知道怎樣去考慮要對單個組件，甚至我們app的頁面測試哪些東西，但從哪裡開始呢?這有點困難。尤其是當你剛剛開始在一個大型應用程序中進行測試時。

那麼這就是你要做的，從用戶的角度考慮你的app，然後問自己:

如果這個app出問題了，哪個部分最讓你心煩意亂?

或者，更普遍地來說:

在這個app中，什麼事情發生錯誤是最糟糕的?

我建議你做一個你的應用程序支持的特性列表，並根據這個標準對它們進行優化。這對你的團隊和經理來說是一個很好的鍛煉。這次會議的附加作用是幫助房間里的每個人理解測試的重要性，並有希望說服他們，在你需要做的所有其他特性工作中，測試應該得到某種程度的優先順序。

一旦你有了這個優先順序列表，那麼我建議你編寫一個單獨的端到端(E2E)測試，以覆蓋大多數用戶在特定用例中經歷的「幸福之路」。通常，你可以通過這種方式覆蓋你的列表中幾個最重要特性的部分。這可能需要一段時間來建立，但它絕對是物超所值。

E2E測試不會給你100%的用例覆蓋率(你甚至都不應該嘗試),也不會給你100%的代碼覆蓋率(無論怎樣，你都不應該對E2E測試記錄這一點),但它會給你一個很好的起點,在很大程度上會增強你的信心。

一旦你寫好了幾個E2E測試之後，那麼你就可以開始為這些E2E測試中缺少的一些邊緣用例編寫一些集成測試，並為這些特性所使用的更複雜的業務邏輯編寫單元測試。從這裡開始，就是隨著時間添加測試的事情了。只是不要為實現100%的代碼覆蓋率報告而煩惱，這不值得花時間。

要了解更多關於建立測試文化和合理的代碼覆蓋目標的信息，我建議你觀看Aaron Abramov在AssertJS 2018上的演講:使用軟體設計原則建立測試模式（https://www.youtube.com/watch?v=_pnW-JjmyXE&list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw ）。

請在這裡閱讀更多關於「不同類型測試之間的區別」的信息: 前端應用程序的靜態測試、單元測試、集成測試和E2E測試（https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests ）。

結論

給你足夠的時間和經驗，你就會形成一種直覺，知道要測試什麼。你可能會犯錯誤，還會有點掙扎。但別放棄!繼續。祝你好運。

英文原文：https://kentcdodds.com/blog/how-to-know-what-to-test

譯者：一瞬

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！