[譯]重新思考單元測試斷言_ZenDei技術網路在線

原文地址：https://medium.com/javascript scene/rethinking unit test assertions 55f59358253f 作者： "Eric Elliott" 「斷言」是編程術語，表示為一些布爾表達式，程式員相信在程式中的某個特定點該表達式值為真，可 ...

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

作者：Eric Elliott

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

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

在此之前，我已經詳細地敘述過每個單元測試必須回答的 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 個問題：

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

滿分為 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
    });
  }
});

被測單元是什麼？ addEntity()
它將做什麼？ given an entity: should read the same entity from the api
實際輸出是什麼？ { id: 'baz', foo: 'bar' }
期望的輸出是什麼？ { id: 'baz', foo: 'bar' }
如何將失敗重現？ 現在，消息中更明確地說明瞭如何重現測試：提供 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 等在內的頂級錄音軟體的用戶體驗做出了傑出貢獻。