我使用RoR創建了自己的小項目，我計劃它具有中小負載。毫無疑問，我開始使用BDD和TDD（Cucumber和RSpec是精確的，但我也對TestUnit有經驗），但是我喜歡它，但是因爲它是我自己的項目，並且它有點啓動 - 我正在改變其中的很多東西，許多要求，許多想法應該如何工作和尋找。因此，使用BDD和TDD編寫代碼時，即使只覆蓋常見情況，也會耗費太多時間。
我該怎麼辦？我應該犧牲BDD和TDD的生產力，直到我有一個堅實的基礎，現在是生產時間，而不是我寫測試的時候？
我現在應該寫嗎，但儘可能少？我現在只應該寫RSpec並忘記黃瓜嗎？或者也許只是TestUnit現在測試模型，因爲它是最重要的，其他所有東西都可以改變？
在此先感謝！如果我的項目變化很快，我應該使用TDD和BDD嗎？
可能是因爲使用BDD/TDD可能會使您的工作效率更高。你說你的需求經常變化，也許可能是因爲改變/編寫測試用例等比編寫實際代碼更加靈活/快速，然後在每次需求改變時銷燬它並編寫新代碼。也許這樣做可以作爲一種過濾器/層來審查你想要創建的變化。在花時間實施它之前，它可能會幫助您瞭解事情是否會起作用。當你實現它時，你當然有TDD的好處，你已經擁有測試套件來確保正確性。
這不是一個政治上正確的答案，我相信這會導致純粹主義者不高興。這裏是：對於一個小而且快速變化的項目，最好只寫代碼並跳過TDD和BDD步驟。否則，你會顯着延遲完成。這不是一個應該始終遵循的規則，但是如果在您的判斷中您瞭解項目的要求，那麼不要爲編寫代碼感到內疚。
就個人而言，如果我重複只是來定義功能，設計，實現等，我傾向於輕鬆測試。這就是說，一旦我用完成了那個部分，我通常會把這些開發釘扔掉，然後用T/BDD交付一個可交付成果。
在我看來，因爲這是你的項目，你真的在駕駛座位。如果您認爲TDD/BDD的優勢比更多實驗/上市時間更快，那麼我會堅持下去。另一方面，如果你真的確定項目是否有腿並且可能在廢料場中結束，那麼在短期內關注更快的學習可能是更好的選擇。我想這是我建議你確定你當前的項目目標並將你的實踐與他們聯繫起來的方式。
雖然這並沒有給出一個非常具體的答案，但我認爲它有點複雜，您可以進行一些更高級別的場景測試，以確保您不會破壞您的某個快速任務功能發生變化，但放棄了TDD/BDD。我個人的經驗是，當我練習TDD時，我感覺更有成效，因爲它幫助我一次專注於解決一個問題，並且發現自己正在進入更好的節奏。
希望有幫助！
布蘭登
嗯，我們在答案中有相似之處。傾向於同意你的看法。 +1（也適用於甜頭像：p） – bas 2013-03-16 08:11:39
因此變得過於費時使用BDD和TDD，即使我只涵蓋常見的情況總是代碼時。
我似乎總是使用TDD提高編碼速度。在執行測試時發現「愚蠢的代碼錯誤」，並更快地找到根本原因因素，然後我將不經過我的單元測試。
對於BDD，如果您的要求傾向於徹底改變，我可以想象，您會推遲測試的要求，直到船開始更加統一的方向。
我會爭辯說，您要使用TDD（可能不是BDD），因爲需求正在發生如此大的變化。 TDD支持可重構的設計+代碼庫，因此易於更改。在一個項目的過程中（即使只有一兩週），使用TDD +重構實際上會比不使用它更快。
這是團隊合作還是單人計劃？ – 2013-03-15 23:12:50
這看起來似乎違反直覺，但我發現有一個好的測試套件可以幫助我快速更改 – 2013-03-15 23:56:21