前言

在做前端測試時，選用合適的測試策略遠比一通狂寫測試更重要，所謂 “方向 > 努力”。

如果選擇了錯誤的測試策略，很容易寫出維護性差和不穩定的測試用例。一旦業務出現變化，用例就全崩了。可能這也是大家討厭寫測試的原因之一吧。

Kent C. Dodds[1] 在這篇文章 《Common Testing Mistakes 》[2] 分享 了 3 個他看到的測試誤區。今天，就把這篇文章分享給大家吧！

翻譯中會盡量用更地道的語言，這也意味著會給原文加一層 Buf，想看原文的可點擊 這里[3]。

誤區一：測試代碼的實現細節

說實話，我非常喜歡這個誤區(詳情可以看這里[4])，因為在測試過程中，它是一個很嚴重的問題，這樣寫測試也不會帶給你對應的信心。下面是一個測試代碼實現細節的例子：

// counter.js
import * as React from 'react'

export class Counter extends React.Component {
  state = {count: 0}
  increment = () => this.setState(({count}) => ({count: count + 1}))
  render() {
    const {count} = this.state
    return <button onClick={this.increment}>{count}</button>
  }
}

// __tests__/counter.js
import * as React from 'react'

// 用 React Testing Library 是很難測代碼實現細節的，所以這里用 enzyme 來測
import {mount} from 'enzyme'
import {Counter} from '../counter'

test('the increment method increments count', () => {
  const wrapper = mount(<Counter />)
  // 千萬別這么做
  expect(wrapper.instance().state.count).toBe(0)
  wrapper.instance().increment()
  expect(wrapper.instance().state.count).toBe(1)
})

為什么說上面是在測代碼實現細節?以及，為什么測代碼細節是不好的呢?像上面那樣過度測試實現細節會帶來兩個結果：

• 我可以在測試完全通過的情況下弄崩業務代碼(比如在 onClick 賦值時故意寫錯變量名)
• 我可以在重構業務代碼的時候弄崩測試用例(例如，把 increment 重命名為 updateCount，測試就崩了，但業務代碼是能正常運行的)

(譯注：作者對重構的理解是：改動業務代碼邏輯時，測試代碼不應該做改動的，因為業務邏輯沒變，只是實現方式變了)

類似這樣的測試用例是最難維護的，因為你要不斷地更新它們(基于上面第二點)，同時，它們也不會給你帶來更多代碼的信心(基于上面第一點)。

誤區二：100% 代碼覆蓋率

另一個誤區就是強求 100% 的代碼覆蓋率。 有趣的是，我經常看到在一些項目里會被強制要求 100%
的覆蓋率。不管這種規定是從哪來的，這其實都是對代碼覆蓋的誤解，因為這樣并不能給你帶來相與之對應的代碼信心。

代碼覆蓋只能告訴你一件事：

• 這行代碼有被測試用例跑過

然而，它沒有告訴你的事有：

• 代碼是否按業務需求來正常工作
• 代碼是否能和項目里其它代碼一起工作
• 項目崩了的時候會發生什么(這里指意外崩潰)

代碼覆蓋率的另一個問題是：每增加一行代碼的覆蓋，整體覆蓋量也會被增加。也就是說，如果你想提高整體覆蓋率，那么在 “支付頁” 添加測試和在 “關于” 頁添加測試的效果是一樣的(整體覆蓋率變高了)。比這更嚴重的另一個問題是：這樣的覆蓋率不能讓你深入地了解你的項目...

目前來說，還沒有一種萬能的解決方案來獲得準確的代碼覆蓋率，畢竟每個項目的需求是不同的。我一般不會過度關注代碼覆蓋率，而是更關注于項目里重要的部分是否覆蓋到位。在確定項目中的關鍵部分之后，我會利用覆蓋率報告來找出還未被測試覆蓋到的邊界情況。

聲明一下，對于開源模塊來說，100% 代碼覆蓋率是完全合理的，因為它們一般更容易達到 100%
覆蓋率(項目不大，而且相對簡單)，而且他們都是很重要的代碼，會被很多別的項目引用。

誤區三：重復測試

相比于集成測試和單測，大多數人吐槽 E2E 最多就是很慢和不可靠。 你是不可能讓單個 E2E
測試既能跑得快，又能像單測那樣穩定的。反正就是不可能的。不過話說回來，單個 E2E 測試會比單測帶來更多代碼信心。在很多情況下，單測是不能像 E2E
那樣帶來那么高的代碼信心的，所以項目中寫點 E2E 測試是肯定值回本的!

當然，上面這么說不代表我們不能讓我們的 E2E 測試跑更快和變得更可靠。其中，重復測試是人們寫 E2E
測試時經常踩的一個坑，這會讓降低整個測試的性能以及可靠性。

我們應該要在隔離環境下執行測試。理論上，每個單獨的 E2E
測試在執行時都應該像不同的用戶使用軟件一樣。這樣的話，每次跑測試都要走一遍注冊登錄流程來創建新用戶了，對吧?看起來好像是對的，然后你每次就要點點按鈕，輸入用戶信息來做注冊登錄。這么做只是為了業務中要用一下用戶的登錄態，是吧?錯!這是不對的!

讓我們回過頭來想：為什么要寫測試?因為這樣你可以交付出更有自信、不容易崩潰的項目呀!假如，你有 100
個測試需要用已登錄的用戶來執行。那你應該要跑多少次注冊/登錄流程來讓你相信代碼是沒問題呢?100 次還是 1 次?正常人都會選 1 次，因為只要 1
次成功，處處都應該成功。因此，剩下的 99 次額外的測試并不會給你帶來任何代碼信心。它們只是在做無用功。

那你應該怎么做呢?既然我們已經搭建好了測試的隔離環境，那么就不應該在測試之間共享同一個
user。我推薦的做法是：當每次要注冊和登錄新用戶時，在項目中發送同一個 HTTP
請求!發送請求肯定比在頁面點擊選中輸入框和輸入用戶名、密碼來得更快，而且會產生更少的假錯誤 (譯注：假錯誤是指：測試失敗了，但是其實應用代碼本身沒任何問題)
。只要你能保證有 1 個能完整跑通注冊/登錄的流程，那么你就不會失去這個登錄注冊流程的信心。

總結

一定要時刻記住我們寫測試是為了提高代碼信心。如果你現在做的事不能讓你提高對代碼的信心，那可以考慮你是否真的要這么做!