BDD - 測試驅動開發

---

---

當您檢視任何關於行為驅動開發的參考資料時，您會發現諸如“BDD 源於 TDD”、“BDD 和 TDD”之類的短語。要了解 BDD 的起源，為什麼說它源於 TDD，以及 BDD 和 TDD 是什麼，您必須瞭解 TDD。

為什麼要測試？

首先，讓我們深入瞭解測試的基礎知識。測試的目的是確保所構建的系統按預期工作。請考慮以下示例。

因此，根據經驗，我們瞭解到在發現缺陷時立即修復它在成本效益方面會更高。因此，有必要在開發和測試的每個階段編寫測試用例。這就是我們傳統的測試實踐所教給我們的，通常被稱為儘早測試。

這種測試方法被稱為最後測試方法，因為測試是在某個階段完成後進行的。

最後測試方法的挑戰

在軟體開發專案中，最後測試方法已經沿用了一段時間。然而，實際上，由於這種方法需要等到特定階段完成後才能進行測試，因此經常由於以下原因而被忽視：

• 階段完成的延遲。

• 緊張的時間安排。

• 專注於按時交付，跳過測試。

此外，在最後測試方法中，應該由開發人員完成的單元測試經常被跳過。發現的各種原因都基於開發人員的心態：

• 他們是開發人員，而不是測試人員。

• 測試是測試人員的責任。

• 他們在編碼方面很有效率，他們的程式碼不會有缺陷。

這導致：

• 影響交付產品的質量。

• 僅將質量責任歸咎於測試人員。

• 修復缺陷的成本很高，交付後。

• 無法獲得客戶滿意度，這也意味著失去回頭客，從而影響信譽。

這些因素促使了正規化的轉變，從而專注於測試。結果是首要測試方法。

首要測試方法

首要測試方法將由內而外（編寫程式碼然後測試）的方式替換為由外而內（編寫測試然後編寫程式碼）的開發方式。

這種方法被整合到以下軟體開發方法中（也是敏捷方法）：

• 極限程式設計 (XP)。

• 測試驅動開發 (TDD)。

在這些方法中，開發人員在編寫程式碼模組的任何一行程式碼之前，都會設計和編寫該程式碼模組的單元測試。然後，開發人員建立程式碼模組，目標是透過單元測試。因此，這些方法使用單元測試來驅動開發。

需要注意的基本點是，目標是基於測試的開發。

紅-綠-重構迴圈

測試驅動開發用於在單元測試的指導下開發程式碼。

**步驟 1** - 考慮要編寫的程式碼模組。

**步驟 2** - 編寫測試

**步驟 3** - 執行測試。

測試失敗，因為程式碼尚未編寫。因此，步驟 2 通常被稱為編寫失敗的測試。

**步驟 4** - 編寫儘可能少的程式碼以透過測試。

**步驟 5** - 執行所有測試以確保它們仍然全部透過。單元測試是自動化的，以方便此步驟。

**步驟 6** - 重構。

**步驟 7** - 對下一個程式碼模組重複步驟 1 到步驟 6。

每個迴圈都應該非常短，一個典型的小時內應該包含許多迴圈。

這也被稱為**紅-綠-重構**迴圈，其中：

• **紅色** - 編寫失敗的測試。

• **綠色** - 編寫程式碼以透過測試。

• **重構** - 刪除重複項並將程式碼改進到可接受的標準。

TDD 流程步驟

下圖說明了 TDD 流程的步驟。

TDD 的優勢

測試驅動開發的好處或優勢是：

• 開發人員需要首先了解期望的結果以及如何在建立程式碼之前對其進行測試。

• 只有當測試透過且程式碼經過重構後，元件的程式碼才算完成。這確保了在開發人員轉到下一個測試之前進行測試和重構。

• 由於在每次重構後都會執行單元測試套件，因此每個元件仍然可以工作的反饋是持續的。

• 單元測試充當始終最新的動態文件。

• 如果發現缺陷，開發人員會建立一個測試來揭示該缺陷，然後修改程式碼以使測試透過並修復缺陷。這減少了除錯時間。所有其他測試也會執行，當它們透過時，確保現有功能不會中斷

• 開發人員可以隨時做出設計決策和重構，執行測試可以確保系統仍在工作。這使得軟體易於維護。

• 開發人員有信心進行任何更改，因為如果更改影響任何現有功能，執行測試會揭示這一點，並且可以立即修復缺陷。

• 在每次連續的測試執行中，所有以前的缺陷修復也會被驗證，並且減少了相同缺陷的重複。

• 由於大部分測試是在開發過程中完成的，因此交付前的測試時間縮短了。

TDD 的缺點

起點是使用者故事，描述系統的行為。因此，開發人員經常面臨以下問題：

• 何時測試？

• 測試什麼？

• 如何知道是否滿足規範？

• 程式碼是否交付業務價值？

關於 TDD 的誤解

行業中存在以下誤解，需要澄清。

驗收 TDD

驗收測試驅動開發 (ATDD) 在開發早期建立使用者故事時定義驗收標準和驗收測試。ATDD 重點關注客戶、開發人員和測試人員之間的溝通和共同理解。

ATDD 的關鍵實踐如下：

• 討論現實場景以建立對領域的共同理解。

• 使用這些場景來確定驗收標準。

• 自動化驗收測試。

• 將開發重點放在這些測試上。

• 使用測試作為即時規範以促進更改。

使用 ATDD 的好處如下：

• 需求明確且沒有功能差距。

• 其他人瞭解開發人員預見的特殊情況。

• 驗收測試指導開發。

TDD 與 BDD

根據 Dan North 的說法，程式設計師在執行測試驅動開發時通常會遇到以下問題：

• 從哪裡開始

• 測試什麼和不測試什麼

• 一次測試多少

• 如何稱呼他們的測試

• 如何理解測試失敗的原因

所有這些問題的解決方案都是行為驅動開發。它已從既定的敏捷實踐中發展而來，旨在使它們更容易為不熟悉敏捷軟體交付的團隊所訪問和使用。隨著時間的推移，BDD 已發展到涵蓋敏捷分析和自動化驗收測試的更廣泛範圍。

TDD 和 BDD 之間的區別在於：

• TDD 描述了軟體的工作方式。

• 另一方面，BDD：

  • 描述終端使用者如何使用軟體。

  • 促進協作和溝通。

  • 強調系統行為的示例。

  • 旨在從示例中得出可執行的規範