BDD可以在「之後」完成嗎？

單元測試是編寫代碼測試的做法。 TDD是「之前」寫作它們的做法。 BDD是編寫行爲/規範驅動測試的慣例。我可以在「之後」寫下BDD嗎？還是我必須在「之前」之前寫下BDD？BDD可以在「之後」完成嗎？

如果你寫BDD「之後」，它不是BDD，那麼它叫什麼？

2012-04-20 Tower

通過行爲驅動開發的定義，你不能代碼後寫進行性能測試，但是這並不意味着這樣做是沒有用的。您可以從首先編寫規格測試中獲得更多好處，但它們仍然可用作應用程序的迴歸系統測試。所以，雖然你在技術上不是在練習BDD，但寫這些測試是個好主意。一個BDD的大福利的是，它引導了特定行爲的發展，使你被後來加入他們失去了很多價值，但他們仍然擔任一些使用。

這是與在TDD的代碼之後寫單元測試。這在技術上不是TDD，但進行測試顯然仍然有用。

來源

2012-04-20 06:12:57 Oleksi

它叫什麼然後如果沒有BDD？ – Tower 2012-04-20 06:14:30

定期開發與行爲/規格測試。：P – Oleksi 2012-04-20 06:14:51

您仍然可以通過手動進行對話和測試來完成BDD。當然，自動化非常有用，但它遠沒有談話那麼重要。 BDD只是旨在幫助開發人員進行對話並將該語言帶入代碼。請不要注意自動化！ – Lunivore 2012-04-20 13:37:51

行爲驅動開發（BDD）是測試驅動開發（TDD）的變化，只是像TDD，你應該先寫你的測試。

有人叫BDD用於TDD做的權利，或者它的方式之意。另外，您可以說BDD是域驅動開發（DDD）和TDD的混合體。

來源

2012-04-20 06:17:38

BDD發展後不BDD，它是驗證，而不是規範的情況。

然而，隨着其他人提到，這並不意味着，在加入驗收測試套件後的，其實沒有價值。在進行進一步的開發（大型重構工作或添加新功能）之前，您將構建一套驗證行爲的迴歸驗收測試。根據經驗我會說如果你要完成這項任務，那麼編寫生產代碼的關鍵開發人員最好遠離編寫驗收測試（希望採用小黃瓜腳本的形式）;那些正在編寫它們的程序可以回到最初的需求文檔（如果有的話），並且絕對是與一些利益相關者合作的。這將有助於確保您編寫的驗收測試更接近規範。

來源

2012-05-25 15:31:23 SaxonMatt

我喜歡觀察根本就是BDD-後編寫驗證的情況。我也非常感謝開發人員在做BDD-After之後忽略了BDD-As-You-Go的其他一些好處。這似乎值得補充的一點是，在實施前寫secenario /測試，然後有檢驗合格也是一種類型的驗證測試本身是健全的。爲已有功能的功能（BDD-After）編寫通過測試可能會讓開發人員疑惑，如果功能崩潰，他們的測試是否會「適當地失敗」。

來源

2012-09-22 16:55:59

BDD可以在「之後」完成嗎？

回答

相關問題