[[408966]]

本文轉載自微信公眾號「勾勾的前端世界」，作者西嶺。轉載本文請聯系勾勾的前端世界公眾號。

TDD 原則

獨立測試

不同代碼的測試應該相互獨立，一個類對應一個測試類(對于 C 代碼或 C++ 全局函數，則一個文件對應一個測試文件)，一個函數對應一個測試函數。

用例也應各自獨立。每個用例不能使用其他用例的結果數據，結果也不能依賴于用例執行順序。

一個角色：開發過程包含多種工作，如：編寫測試代碼、編寫產品代碼、代碼重構等。做不同的工作時，應專注于當前的角色，不要過多考慮其他方面的細節。

測試列表

代碼的功能點可能很多，并且需求可能是陸續出現的，任何階段想添加功能時，應把相關功能點加到測試列表中，然后才能繼續手頭工作，避免疏漏。

測試驅動

即利用測試來驅動開發，是TDD的核心。要實現某個功能，要編寫某個類或某個函數，應首先編寫測試代碼，明確這個類、這個函數如何使用，如何測試，然后在對其進行設計、編碼。

先寫斷言

編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，然后編寫必要的輔助語句。

可測試性

產品代碼設計、開發時應盡可能提高可測試性。每個代碼單元的功能應該比較單純，“各家自掃門前雪”，每個類、每個函數應該只做它該做的事，不要弄成大雜燴。尤其是增加新功能時，不要為了圖一時之便，隨便在原有代碼中添加功能，對于 C++ 編程，應多考慮使用子類、繼承、重載等OO方法。

及時重構

對結構不合理，重復等“味道”不好的代碼，在測試通過后，應及時進行重構。

小步前進

軟件開發是復雜性非常高的工作，小步前進是降低復雜性的好辦法。

TDD 的優點

• 保證代碼質量，因為先編寫測試，所以可能出現的問題都被提前發現了;
• 促進開發人員思考，有利于程序的模塊設計;
• 測試覆蓋率高，因為后編寫代碼，因此測試用例基本都能照顧到;

TDD 的缺點

• 代碼量增多，大多數情況下測試代碼是功能代碼的兩倍甚至更多;
• 業務耦合度高，測試用例中使用了業務中一些模擬的數據，當業務代碼變更的時候，要去重新組織測試用例;
• 關注點過于獨立，由于單元測試只關注這一個單元的健康狀況，無法保證多個單元組成的整體是否正常;

個人理解在前端應用實際開發過程中 TDD 更適合開發純函數庫，比如 Lodash、Vue、React 等。

BDD

TDD 最大一個問題是在于開發人員最終做出來的東西和實際功能需求可能相偏離，為了解決這一問題有人發明了 BDD。BDD(Behavior-driven development)行為驅動開發，是測試驅動開發延伸出來的一種敏捷軟件開發技術。

BDD 解決的另外一個關鍵問題就是如何定義 TDD 或單元測試過程中的細節。一些不良的單元測試的一個常見問題是過于依賴被測試功能的實現邏輯。這通常意味著如果你要修改實現邏輯，即使輸入輸出沒有變，通常也需要去更新測試代碼。這就造成了一個問題，讓開發人員對測試代碼的維護感覺乏味和厭煩。

BDD 核心目的是為了解決 TDD 模式下開發和實際功能需求不一致而誕生，BDD 不需要再面向實現細節設計測試，取而代之的是面向行為來測試。它是從產品角度出發，鼓勵開發人員和非開發人員(產品、QA、客戶等)之間的協作。由于 BDD 的核心是關注軟件的功能測試，所以 BDD 更多的是結合集成測試進行，它是黑盒的。

BDD 的開發流程

1、開發人員和非開發人員一起討論確認需求

2、以一種自動化的方式將需求建立起來，并確認是否一致

3、最后，實現每個文檔示例描述的行為，并從自動化測試開始以指導代碼的開發

這樣做使得每一次的更改都較小并快速迭代，每次需要更多信息時都將其上移。每次自動化并實現一個新示例時，便為系統添加了一些有價值的內容，并準備響應反饋。

理想中的 BDD 解決方案最流行的是 Cucumber。它的協作流程是這樣：

1、開發人員與產品、測試、客戶等人員溝通確認需求

2、使用統一的 Gherkin 語法將功能需求轉換為需求文檔

用描述性自然語言定義的測試，客戶、測試人員和開發人員都能看得懂，能達成共識，這種語法叫做 Gherkin Syntax，小黃瓜語法。

• 以關鍵字 Scenario、Feature 等來描述場景
• 以關鍵字 Given、When、Then 來描述步驟

Feature: 添加任務 
 
  Scenario: 在輸入框中輸入任務名敲回車確定，輸出到任務列表中 
    Given "Hello World" 
    When 在輸入框中敲回車 
    Then 任務列表增加一個名稱為 "Hello World" 的任務 
 
  Scenario: 在輸入框中輸入空內容，不輸出到任務列表中 
    Given "" 
    When 在輸入框中敲回車 
    Then 任務列表中不增加任何內容 

Cucumber 讀取使用 Gherkin 語法描述的純文本形式的可執行規范，并驗證該軟件是否滿足那些規范所說的內容。規范包含多個示例或方案。

每個方案都是 Cucumber 要執行的步驟的列表。Cucumber 驗證軟件是否符合規范，并生成一個報告，指出每種情況的成功或失敗。

3、開發人員根據 Gherkin 編寫測試用例

4、編寫代碼使測試通過

5、新增功能重復上述步驟

BDD 注重的是產品功能，可能無法保證很好的代碼質量和測試覆蓋率，所以還有人提出一種方案就是 BDD + TDD。

BDD

– 需求分析

– 描述需求定義文檔

– 編寫集成測試用例

TDD

– 編寫單元測試用例

– 編寫代碼使單元測試通過

– 重構優化

編寫代碼使集成測試通過

增加功能重復上述步驟

個人理解也可以把 BDD 看作是在需求與 TDD 之間架起一座橋梁，它將需求進一步場景化，更具體地描述系統應該滿足哪些行為和場景，讓 TDD 的輸入更優雅、更可靠。

還有一種更輕量的 BDD 方案就是以集成測試為主的開發方案。

• 需求分析
• 編寫集成測試用例
• 運行測試
• 代碼實現使測試通過
• 重構優化
• 增加功能重復上述步驟

BDD 的優點：

• 由于側重于需求功能的完整度，所以能給開發人員增加更多對程序的信心
• 由于僅關注功能，不關注實現細節，有利于測試代碼和實際代碼解耦
• 由于大多數為編寫集成測試，相比 TDD 有更好的開發效率

BDD 的缺點：

• 因為以功能性的集成測試為主，因此不是那么關注每個函數功能，測試覆蓋率比較低
• 沒有 TDD 那么嚴格的保證代碼質量

TDD vs BDD

個人推薦：

• 建議開發功能函數庫使用 TDD 方案
• 建議開發業務系統使用 BDD 方案

俗話說生活就像一場旅程，不必在乎目的地。雖然對生活來說這可能是正確的，但對開發應用程序來說卻恰恰相反，你可以選擇單獨使用其中一種方法，也可以綜合使用這幾個方法以取得更好的效果。只要是編寫可節省時間的、有價值的測試就可以，如何編寫無關緊要。

前端自動化測試的權衡利弊

當我們開始編寫自動化測試時，可能想要測試所有的東西。每個搬磚仔可能都體會過未經測試的應用程序帶來的痛苦，但在測試過程中，很快我又學到了另一課——測試會減緩開發速度。

在編寫測試時，請務必牢記編寫測試的目的。通常，測試的目的是為了節省時間。如果你正在進行的項目是穩定的并且會長期開發，那么測試是可以帶來收益的。

但是如果測試編寫與維護的時間長于它們可以節省的時間，那么你根本不應該編寫測試。當然，在編寫代碼之前你很難知道通過測試可以節省多少時間。但是，假設你正在一個短期項目中創建原型，或者是在一個創業公司迭代一個想法，那你可能不會從編寫測試中獲得收益。

凡事都有兩面性，軟件測試也不是銀彈，好處雖然明顯，卻并不是所有的項目都值得引入測試框架，畢竟維護測試用例也是需要成本的。對于一些需求頻繁變更、復用性較低的內容，比如活動頁面，讓開發專門抽出人力來寫測試用例確實得不償失。

而適合引入測試場景大概有這么幾個：

• 需要長期維護的項目。它們需要測試來保障代碼可維護性、功能的穩定性。
• 較為穩定的項目、或項目中較為穩定的部分。給它們寫測試用例，維護成本低。
• 被多次復用的部分，比如一些通用組件和庫函數。因為多處復用，更要保障質量。

 

測試確實會帶給我們相當多的好處，但不是立刻就能夠體會到。測試就像保險，如果身體健康順順利利，幾十年可能都用不上。測試也一樣，寫了可以買個放心，這就是對代碼的一種保障，有 bug 可以盡快測出來，沒 bug 最好，但不能說“寫那么多測試，結果測不出 bug，是浪費時間”。