上一篇中詳細講解了 TDD，此篇將會重於 BDD/ATDD 的概念為主
目的是希望有個 TDD 基底後，了解 BDD/ATDD 會更加順利
BDD（Behaviour-Driven Development）是一種開發流程，中文是「行為驅動開發」。
而 BDD 比 TDD 更進一步，在寫測試前先寫測試規格書，同時它會更從使用者的角度建立相關的測試情境。
然後這份測試規格會用更接近人類語意的自然語言來描述軟體功能和測試案例。
而且這份規格不是單純的敘述文件，而是一份「可以被執行的規格」，也就是可以被轉成自動化測試。
BDD 的步驟
Feature: 一句話簡介這份規格書所涵蓋的軟體功能
對這份規格書更多的介紹 (非必要，不影響自動測試)
介紹....
介紹....
Scenario: 要測試的測試案例 1
Given 前提條件是....
When 我做了某件事....
Then 結果應該得到...
Scenario: 要測試的測試案例 2
Given 前提條件是....
When 我做了某件事....
Then 結果應該得到...
BDD 的好處：
較為著名的 BDD 測試框架是 Cucumber
實作教學可參考: BDD/TDD差別是什麼？ 手把手用 Cucumber 實作示範BDD
BDD 主要是從使者用的角度測試產品的行為方式，而 TDD 則單獨測試產品中的小功能。
TDD 關注的是特定方法結果，而 BDD 關注更複雜使用者場景的結果。
簡單說明:
TDD ：【我需要以特定方式執行預先設計的測試，而不用擔心結果】
BDD ：【只要結果在預定條件下是正確的，這個過程就無關緊要】
答案:【可以】
BDD 和 TDD 雖然有這不同的地方，但兩者是並不相互排斥。
反之讓兩者並存時，是可以確保有更高程度的測試情境及測試案例的效率。
e.g. 開發團隊可以使用 BDD 方法與 TDD 一起進行更複雜的測試時，這一來可以從開發的角度處理技術上的細微差別，二來還可以評估使用者的行為。
為了實現這些小細節，開發可以撰寫更加單獨的測試單元來維護不同組件。
這時考慮到這些相同的組件是可以在測試情境上相互搭配使用，對測試結果來說也會更有效益。
ATDD(Acceptance Test-Driven Development) 是一種開發流程，中文是「驗收測試驅動開發」。ATDD 是一種將驗收標準轉化為測試的開發技術。
驗收測試的書寫方式，通常是非軟體工程師也能閱讀的文件，可以是可執行的自動化測試，但也可以不是，這點與 TDD 不太相同。
ATDD 的目的在於讓工程師與團隊其他角色，能夠互助合作，並對產品需求達成共識，互相了解要完成什麼內容。
ATDD 的步驟：
所以 ATDD 相比 TDD BDD 不同之處是，ATDD 在規格撰寫之前，就開始先條列驗收的測試
再依照驗收測試定義規格書，其實有點像是我們常說的 User Story，但差別是【驗收的方式及標準】。
User Story 為簡單說明使用者行為，以表示這個情境符合需求即可。
ATDD 不僅僅是需求，也會更著重於解決潛在的業務問題。
User Story 目標：
ATDD 目標：
User Story 範本：
與 User Story 相比，了解驗收標準以及所有其他條件非常重要
因為如果一個需求是模糊的或不完整的，它可以延後到下一個 Sprint 才進去進行
但是，如果發現沒有驗收標準，則無法確定是否滿足 User Story。
ATDD 範本：
當有個 User Story 為
以下驗收標準為：
| TDD | BDD | ATDD |
|---|---|---|
| TDD 專注於功能的實現 | BDD 專注於系統的行為 | ATDD 專注於捕捉準確的需求 |
| 主要是開發人員參與編寫單元測試 | 開發、QA 和使用者參與此過程 | 開發、QA 和使用者參與此過程 |
| 用 Python、Java 等程式語言撰寫 | 用簡單易懂的英文敘述方式 | 用簡單易懂的英文敘述方式 |
| 非技術人員不容易理解這一點 | 非技術人員很容易理解這一點 | 非技術人員很容易理解這一點 |
| 重點是編寫單元測試 | 重點是理解需求 | 重點是編寫驗收測試 |
| TDD 中使用的工具有 JDave、Cucumber、JBehave、Spec Flow、BeanSpec、Gherkin Concordian、FitNesse、Junit、TestNG、NUnit 框架、Selenium 工具 | BDD 中使用的工具有 Gherkin、Dave、Cucumber、RSpec、Behat、Lettuce、JBehave、Specflow、BeanSpec、Concordian、MSpec、Cucumber with Selenium / Serenity | ATDD 中使用的工具有TestNG、FitNesse、EasyB、Spectacular、Concordian、Thucydides、Robot Framework |
ATDD、BDD 與 TDD 的本質其實是相同的設計思維，先從要做什麼開始思考，接著是如何驗證，最後才是寫內容達成驗證。
最初的 TDD 從單元測試出發，而 ATDD 與 BDD 則是從需求面切入，基於 TDD 擴展了測試的層面，讓 TDD 的應用更加寬廣。
iThome鐵人賽
看影片追技術