持續集成始終與測試驅動開發結合在一起？

Question

我參與了一個項目，我們正在使用Continuous Integration服務器和NUnit進行單元測試和集成測試。

前一天有客戶問我們，如果我們在代碼之前寫測試......那麼，是不是這樣做總是這樣。特別是當我們想要測試複雜的技術問題以首先了解問題和可能的解決方案時。

我想知道我們是否仍然可以將我們的開發流程視爲遵循敏捷開發，對客戶說，不要說謊。

Answer 1

我認爲你在這裏混合的東西。

測試驅動開發（TDD）並不一定意味着您正在使用敏捷方法。當然，最好的做法是我們許多使用敏捷的人，但TDD也可以用在瀑布過程中，替換/補充規範。

持續集成意味着讓團隊至少每天生成集成代碼。這不僅會迫使團隊中的每個成員不得不持續合併/簽入，而且還會確保您實際上可以發佈每個構建。統一構建過程會迫使您克服「在我的機器上操作」的問題。因爲你可以每天都做一次發佈，所以它支持一個敏捷的過程，即使它並不是嚴格意義上的絕對必要的。

使用測試並將它們集成到構建過程中是一種使用自動質量保證來豐富您的構建過程並深化實際測試集成（完整性）的級別的方法。

Answer 2

只要您在小型迭代中開發，關注於獲得工作產品而不是獲取大量文檔，並且客戶持續參與項目，那就是敏捷開發。單元測試，TDD和集成測試當然是好的和非常明智的做法，但他們並不決定您的項目是否敏捷。

Answer 3

在沒有自動測試的情況下，CI僅驗證源代碼管理下的代碼是否保持在修訂版本之間的可編譯狀態，並且單步構建工作正常。雖然這很有用，但它不如自動驗證那樣有效，因爲在修訂之間代碼的正確性得以維持。

說了這麼多，我寧願有一些檢查之間的代碼驗證比沒有。我寧願有部分代碼覆蓋或一組不完整的功能測試。或更糟。