筆者最近在研究BDD，儘管在做BDD(行為驅動開發，或者ATDD，可接受性測試)的時候，不一定需要TDD（測試驅動開發），或者在做TDD（測試驅動開發）的時候也不需要BDD（為驅動開發）。但是如果專案對程式碼覆蓋率有質量要求的時候，我想BDD一般很難達到很高的程式碼覆蓋率（比如90%），因為其是一種比普通單元測試更高粒度的使用者需求，那麼在這種情況下，如何在BDD(行為驅動開發)把TDD（測試驅動開發）結合起來，從而提高程式碼的測試覆蓋率呢？為了解釋這個問題，首先咱們來看BDD和TDD分別是什麼，其特點是什麼。

• Behavior Driven Development，行為驅動開發是一種敏捷軟體開發
  的技術，它鼓勵軟體專案中的開發者、QA和非技術人員或商業參與者之間的協作。BDD最初是由Dan North在2003年命名，它包括驗收測試和客戶測試驅動等的極限程式設計的實踐，作為對測試驅動開發的迴應。在過去數年裡，它得到了很大的發展。其中支援BDD的框架，有Cucumber，Spec，Spock等開源專案。

    

•  TDD是（Test-Driven Development）的英文簡稱，是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能程式碼之前，先編寫單元測試用例程式碼，測試程式碼確定需要編寫什麼產品程式碼。TDD雖是敏捷方法的核心實踐，但不只適用於XP（Extreme Programming），同樣可以適用於其他開發方法和過程,一般高階語言都會提供某種xUnit框架來實現TDD，比如Java中的JUnit，.NET中的NUnit。 其基本步驟和週期如下。

從上面的BDD和TDD的定義已經流程，我們可以知道，其實BDD已經包含了TDD，但是因為其是面向可接受性測試的，是直接面向客戶的，其測試案例（Test Case）的粒度又不可能細化到程式碼中每一個方法或者程式碼中的分支路徑（if else； 異常等等），否則就變成了單元測試；但是如果其描述的可接受性測試，不覆蓋程式碼中每一個方法或者程式碼中的分支路徑的話，如果保證交付的軟體產品的方法級別的程式碼質量呢？這個時候，肯定需要有某一個契合點能把BDD和TDD結合起來，具體結合方式請看下圖示意。

從上面的圖，我們可以看出。BDD（ATDD）是一種一種更高效的開發策略，其能幫助開發者精確的把握客戶的需求。是一種高層次的行為方式。而低層次，需要更進一步細化的細節的實現，則需要使用TDD來進行分解BDD（ATDD）的需求規格說明。換句話說，TDD是為了保證開發者正確的做開發；而BDD（ATTD）則是保證了開發出來的產品或者軟體是正確的。因此，其結合的契合點就是，在上層，還是通過和客戶商量定義好的測試場景，進行一一列出，然後把需要實現的粗粒度測試場景（更面向使用者的），分解成開發人員能夠實現的方法級別的粒度，從而能夠使用上TDD，從而不但能讓客戶和開發人員需要文件，只需要看我們的BDD中的功能規則說明只能知道該軟體是否滿足他們的需求，同時也能達到目標的程式碼覆蓋率，從而進一步提高產品質量。