我一直在建議我的工作場所通過以場景格式編寫高級規範來實現行爲驅動開發，並且可以想象爲它編寫測試。BDD/TDD vs JAD？
我知道，對檢驗的規範工作趨於increase developer productivity。我已經可以想到幾個例子，我們自己的項目就是這種情況。
但是很難證明這對企業的價值。
這是因爲我們已經有一個適當的聯合應用開發（JAD）過程，其中開發人員，管理，用戶體驗和測試人員都聚在一起一套共同的要求一致。
因此，他們問，爲什麼開發人員應該對付測試人員創建的測試用例？這些是用於驗證的，並且基於UX團隊創建的更高級別規範，開發人員目前正在開發這些規範。
他們說，這對開發人員來說已經足夠了，並且不需要改變規範的寫法。
他們似乎有一個觀點。
什麼是BDD/TDD的實際好處，如果你已經有了一個測試團隊誰的測試用例與目前提供給開發者的更高級別的規格完全兼容？
如果你想說服他們，這會有所幫助，你需要做的主要事情是確定它會解決問題。
在你的情況下發生了什麼，你認爲這會改善？
BDD的主要優勢在於改善利益相關者和開發者之間的溝通。
如果要製作失敗了這些驗證測試的代碼，那麼開發者們從不同的測試，這意味着規範不夠明確，BDD肯定可以改善這種狀況瞭解你的天賦。
也有過程，作爲一個開發者，你可以在工作，在不改變整個團隊的進程的一部分。如果您專注於單元測試級別並進行傳統的測試驅動開發，那可能會使您的工作效率更高。
這可能有助於想想BDD的最輕形式;作爲圍繞特定場景的討論。
你有你的用例。你有你的要求。現在你想驗證你對這些有很好的理解。因此，有人 - 也許是開發人員，也許是一個測試人員 - 說，「好吧，只是爲了驗證我明白...因爲我們以<這個>開始，當用戶做<這個>然後<這個>應該發生。對？」
測試人員會說：「是的，沒錯。」
然後UX或分析師說：「好吧，除非<這個其他上下文存在>」。
通過圍繞場景進行討論，確保每個人都有共同理解所花費的時間大大減少。我們通常會對顯而易見的場景進行研究並關注邊緣案例;以新的領域術語，部門之間不同的概念，與遺留系統的困難交互。
開發人員並沒有真正從測試案例中脫穎而出。他們按要求和驗收標準工作，其工作方式與他們的工作方式完全相同。測試用例就是他們可能期望的事物的一個例子;用戶可以從中受益或傳遞系統價值的場景。自動執行這些測試用例可能很有用，因爲測試工作量大致與代碼庫的大小成比例地增加。
BDD在需求或領域存在高度不確定性的項目中效果最佳，人們的理解差異很大。如果你的項目已經工作，那就堅持下去。也許你可以看看創意和實現它們之間的最大差距在哪裏，如果BDD幫助你在這個空間中使用它，否則挑別的東西。無論如何，你所做的和BDD過程聽起來非常相似。
這是一個很好的問題，事實上這是BDD的「底線」問題。 TDD或編寫單元測試的主要挑戰之一是開發人員似乎無法獲得事物的全貌和業務視角。通過編寫規範和生成單元測試來測試實際的「業務」場景，有助於開發人員提高自己的「技巧」並掌握業務視角。看看這篇文章瞭解更多詳細信息，
http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/
我只是碰到這種問題就來了，我想我會權衡，因爲它真的是一個很有趣的問題。
如果整個團隊都感覺它已經壞了，並且最終的結果是一個失敗的項目，那麼這個方法只會被打破。
如果現在的系統運行良好，那麼你真的需要問自己：「即使我更喜歡BDD/TDD，我是否可以像這樣工作？」。如果你的答案是否定的，並且你覺得你可能對任何其他系統工作不滿意，那麼這也許表明你的職業需要轉移到別處。如果是，那麼擁抱這個系統。
其實，如果是我，我會擁抱一個新系統。首先，如果讓你有機會熟悉它，那麼你就有時間對相對的優點和缺點做出更明智的判斷，並且憑藉這些知識，你可以在稍後的日期提出可能的改進建議是必要的。
在一天結束的時候，一種方法只能達到最終結果。工作軟件，以及所有利益相關者的滿意度。
:-)
或者他可以使用上下文規範框架的MSpec而不是TDD。深入瞭解BDD及其生成的英語報告的思維。如果人們看到單元測試報告，並希望他們爲他們的高級測試提供這樣的表達式報告，那麼您可以以這種方式向他們出售BDD。 – nick 2011-01-10 21:35:22