[譯]重新思考單元測試斷言

格子熊發表於2019-01-01

原文地址：https://medium.com/javascript-scene/rethinking-unit-test-assertions-55f59358253f

作者：Eric Elliott

「斷言」是程式設計術語，表示為一些布林表示式，程式設計師相信在程式中的某個特定點該表示式值為真，可以在任何時候啟用和禁用斷言驗證，因此可以在測試時啟用斷言而在部署時禁用斷言。同樣，程式投入執行後，終端使用者在遇到問題時可以重新啟用斷言。

每當測試失敗的時候，靠譜的自動化測試總能生成一份優秀的錯誤報告（bug report），但是很少有開發者花時間去思考一個好的錯誤報告需要哪些資訊。

在此之前，我已經詳細地敘述過 每個單元測試必須回答的 5 個問題 ，所以這次我們將它們一筆帶過。

  1. 被測單元是什麼（模組，函式，類，等等）？
  2. 它將做什麼？
  3. 實際輸出是什麼？
  4. 期望的輸出是什麼？
  5. 如何將失敗重現？

許多測試框架允許你忽略這些問題中的一個或者多個，這會導致錯誤報告並不實用。

讓我們看一下使用一個虛擬測試框架的示例，該框架提供常用的 pass() 以及 fail() 斷言。

describe(`addEntity()`, async ({ pass, fail }) => {
  const myEntity  = { id: `baz`, foo: `bar` };
  try {
    const response = await addEntity(myEntity);
    const storedEntity = await getEntity(response.id);
    pass(`should add the new entity`);
  } catch(err) {
    fail(`failed to add and read entity`, { myEntity, error });
  }
});

我們走在正確的軌道上，但是我們遺漏了一些資訊。讓我們嘗試使用此測試中提供的資料回答 5 個問題：

  1. 被測單元是什麼？ addEntity()
  2. 它將做什麼？ should add the new entity
  3. 實際輸出是什麼？ 哎呀，我們不知道。我們沒有將這些資料提供給測試框架。
  4. 期望的輸出是什麼？ 我們再一次的不知道。我們這裡沒有測試返回值。相反，我們假設它不丟擲，一切都按照預期執行——但是如果沒有呢？如果函式返回一個值或者是 promise ，我們應該測試結果值。
  5. 如何將失敗重現？ 我們可以在測試設定中看到這一點，但我們可以更明確地說明這一點。例如，對你輸入的東西進行簡單的描述以便讓我們更好地理解測試用例的意圖。

滿分為 5 分的情況下，我的得分為 2.5 分。這項測試沒有完成它應盡的職責。顯然沒有回答每個單元測試必須回答的 5 個問題。

大多數測試框架的問題在於它們的功能太過強大，你可以輕鬆地使用它們提供的各種 “方便（convenient）” 斷言，以至於忘記了在測試失敗時實現測試的最大價值。

在失敗階段，編寫測試問題讓我們更加容易弄清楚出了什麼問題。

在 每個單元測試必須回答的 5 個問題 ，我這樣寫道：

equal() 是我最喜歡的斷言。如果每個測試套件中唯一可用的斷言是 equal()，那麼世界上幾乎所有的測試套件都會更好。

自從我寫這篇文章以來的幾年裡，我一直堅持著我的這一信念。雖然測試框架忙於新增更多 “方便” 斷言，但我卻在 Tape（譯者注：一個開源測試框架） 上進行了一層簡單的封裝，使它只暴露了一個深度的相等斷言。換句話說，我最低程度地使用了 Tape 庫，並刪除了一些功能，以提高測試體驗。

在 RITE Way 測試原則的影響下，我將封裝庫稱為 RITEway。RITE Way 測試應該是這樣的：

  • 可讀（ Readable ）
  • 隔離（ Isolated ）（用於單元測試）或整合（ Integrated ）（用於功能或整合測試，測試應該隔離並且整合元件 / 模組）
  • 徹底（ Thorough ）
  • 明確（ Explicit ）

RITEway 強制你編寫可讀，隔離以及徹底的測試，因為這是你使用 API 唯一的方法。由於編寫測試斷言是如此簡單，以至於你將沉迷於編寫測試，這使得你更容易進行徹底的測試。

這是 RITEway 中 assert() 的 函式簽名：

assert({
  given: Any,
  should: String,
  actual: Any,
  expected: Any
}) => Void

斷言必須位於一個 describe() 塊中，它的第一個引數將作為單元測試的一個標籤。完整的測試如下：

describe(`sum()`, async assert => {
  assert({
    given: `no arguments`,
    should: `return 0`,
    actual: sum(),
    expected: 0
  });
});

它的執行結果如下所示：

TAP version 13
# sum()
ok 1 Given no arguments: should return 0

讓我們再看看上面的 2.5 分的測試，看看我們能否提高我們的分數：

describe(`addEntity()`, async assert => {
  const myEntity  = { id: `baz`, foo: `bar` };
  const given =  `an entity`;
  const should = `read the same entity from the api`;
  try {
    const response = await addEntity(myEntity);
    const storedEntity = await getEntity(response.id);
    assert({
      given,
      should,
      actual: storedEntity,
      expected: myEntity
    });
  } catch(error) {
    assert({
      given,
      should,
      actual: error,
      expected: myEntity
    });
  }
});
  1. 被測單元是什麼？ addEntity()
  2. 它將做什麼？ given an entity: should read the same entity from the api
  3. 實際輸出是什麼？ { id: `baz`, foo: `bar` }
  4. 期望的輸出是什麼？ { id: `baz`, foo: `bar` }
  5. 如何將失敗重現？ 現在，訊息中更明確地說明了如何重現測試：提供 given 以及描述。

很好！現在我們通過了測試的測試。

一個深度相等斷言已經足夠了嗎？

在過去的一年半中的幾個大型專案中，我幾乎每天都使用 RITEway。通過介面的簡單化，我們將其提升了一些，但是我從來沒有想過另外的斷言，我們的測試套件是我在整個職業生涯中見過的最簡單，最易讀的測試套件。

我認為是時候與世界其他地方分享這項創新了。如果你想開始使用 RITEway ：

npm install --save-dev riteway

它會改變你對測試軟體的看法。

簡而言之：

測試越簡單越好（Simple tests are better tests）

附：我在本文中一直使用 “單元測試” 這個術語，這僅僅是因為它比 “自動化軟體測試” 或 “單元測試、功能測試以及整合測試” 更容易寫，但是我在本文中所說的關於單元測試的所有內容都適用於我能想到的每個自動化軟體測試。我也喜歡這些比 Cucumber/Gherkin 更好的測試。

下一步

EricElliottJS.com 的會員可以獲得有關測試驅動開發的視訊課程，如果你還不是會員，請立即前往 註冊 。

Eric Elliott 是 “Programming JavaScript Applications” （O’Reilly）的作者，也是軟體導師平臺 DevAnywhere.io 的創始人。 他為 Adobe Systems，Zumba Fitness，華爾街日報，ESPN，BBC 以及包括 Usher，Frank Ocean，Metallica 等在內的頂級錄音軟體的使用者體驗做出了傑出貢獻。

相關文章