因爲我聽說過BDD（行爲驅動開發）如何BDD補充TDD

我一直在想，如果它補充TDD？它在Web開發中有用嗎？作爲一個繁忙的.net Web開發人員，值得花時間在BDD以及TDD上嗎？當我經歷它時，我發現它很有趣，但我很困惑它對我們有什麼用處！因爲我聽說過BDD（行爲驅動開發）如何BDD補充TDD

我所遇到的這句話，但到底是什麼，它實際上意味着什麼呢？

雖然這些工具通常使用專門開發的BDD 項目，它們可以被看作是支持測試驅動開發模具的專業形式。這些工具有助於將自動化功能添加到作爲BDD核心主題的無處不在的語言中。

來源

2013-10-02 Neel

首先，一些定義;

TDD是測試驅動開發，顧名思義，我們生產推動我們發展的流程測試。它通常與Red-Green-Refactor循環一起描述。所以實際上我們編寫了一個單元測試，但它失敗了，給了我們一個紅色狀態，然後我們修復了我們應用程序的代碼，直到我們通過測試，給我們一個綠色狀態，最後我們重構了我們的應用程序代碼和測試代碼我們有很好的設計。良好的TDD通過將每個測試集中在我們想要測試的類中的單個方法上，並注入模擬的依賴關係，因此我們正在測試儘可能少的代碼量，這導致測試套件出現單個錯誤，導致單個錯誤。

BDD是行爲驅動開發，這裏的行爲是我們的設計過程的驅動因素。當您遵循BDD流程時，您將與人員進行交流，以確定您的應用程序應如何運行，其功能是什麼，並捕獲應該運行的場景的一些示例。實際上，我們也可以考慮BDD是一個循環，功能，應用程序應該有，驗證應用程序適用於所有場景，可能重構我們的測試，使他們最有意義，並重復一遍。 BDD測試通常需要許多類協作才能生成單一業務功能，因此即使一個bug觸發了單一故障，您仍然有大量代碼來追蹤相關代碼。

在這一點上，你可以看到，BDD工作在比TDD較高的水平，其實我已經看到成功地用於驅動TDD內循環不止一個組織BDD外循環，即

 
Define new business feature 
---> Add scenario and test: BDD Red 
|  -> Add Unit test: TDD Red 
| | Add application code: TDD Green 
|  -- Refactor code: TDD refactor 
| Scenario passes: BDD green 
--- Refactor feature and scenarios: BDD refactor 
Feature complete

Gojko Adzic在他的演講中描述得更好TDD:Breaking the mould

它在Web開發中的實際用途如何？ BDD在用於收集需求的過程以及通過BDD工具方面非常有用，可以自動確認您的代碼庫具有業務需要的所有功能。我發現BDD最適合與許多類合作的集成風格測試，而不是單一測試，只關注單一方法。

您將使用BDD構建您的應用程序邏輯，並且您可以使用它來測試您的大部分網站。我個人會迴避測試用戶界面，而是使用諸如「用戶搜索BDD」之類的語言工作在代碼隱藏中，但是有些人使用Selenium並編寫測試來討論點擊和測試框「當用戶輸入搜索文本框中的BDD然後單擊搜索按鈕「。

是否值得花時間在BDD上以及作爲.net的繁忙Web開發人員使用TDD？

希望現在你應該能夠爲自己回答這個問題。您需要確定將BDD引入您的流程會帶來多大的收益。您的收益將取決於您選擇的團隊規模和工具等因素。

我注意到您正在通過用nBehave標記您的問題來查看BDD工具的純文本規格表單。這使您可以讓一個BA團隊處理純文本場景並將其提交回來（儘管不要將它們全部留給他們，您需要一些技術輸入來保持場景的一致性）。其他形式的工具（如mSpec）以另一種方式工作，使用C＃描述場景並生成純文本作爲構建過程的結果。我個人使用SpecFlow，它具有nBehave的所有優點，但它的測試可以通過nUnit運行器，resharper和您的構建服務器運行。但是，您可能希望將集成測試與單元測試分開，並報告不同級別的覆蓋範圍。

最後