版本控制和測試驅動開發

Question

測試驅動開發的標準過程似乎是添加一個測試，看它失敗，編寫產品代碼，查看測試通過，重構，並將其全部檢入源代碼控制。

是否有任何內容允許您檢出測試代碼的修訂版x和生產代碼的修訂版x-1，並確定您在修訂版x中編寫的測試失敗？ （我會對任何語言和源代碼管理系統感興趣，但我使用ruby和git）

有些情況下，您可能會添加已通過的測試，但它們會比開發更加驗證。

Answer 1

幾件事情：

1. 重構試驗後，再次運行測試
2. 然後，重構代碼，然後再次運行測試
3. 然後，你不必檢查在馬上，但你能

在TDD中，存在補充說，通過測試沒有意義。這是浪費時間。爲了增加代碼覆蓋率，我一直在試圖這樣做，但是代碼應該已經被實際上首先失敗的測試所覆蓋。

如果測試不首先失敗，那麼您不知道您添加的代碼是否修復了問題，而且您不知道測試是否真的測試了任何內容。它不再是測試 - 它只是一些代碼，可能會或可能不測試什麼。

Answer 2

如果您將生產和測試代碼保存在不同的版本區域（例如單獨的項目/源代碼樹/庫/等）中，大多數版本控制系統允許您檢出以前版本的代碼並重建它們。就你而言，你可以簽出生產代碼的x-1版本，重新構建它，然後針對新建/部署的生產可部署運行測試代碼。

有一件事可能會有所幫助，那就是在發佈時標記/標記所有代碼，以便您可以輕鬆獲取代碼以前版本的整個源代碼樹。

Answer 3

有什麼事情讓你 退房修訂x的測試代碼， 和修訂X-1的生產 代碼，並看到你 寫在改版X測試失敗？

我認爲你正在尋找關鍵字持續集成。在版本控制系統中有許多工具實際上被實現爲post-commit掛鉤（也就是每次提交後在服務器/中央存儲庫上運行的東西）：例如，他們將在每次提交後運行單元測試，並通過電子郵件發送提交者if修訂引入了迴歸。

這樣的工具是完全能夠檢測哪些測試新，從來沒有從用於傳遞老測試通過，目前最近提交，這意味着使用TDD和持續集成完全就是失敗的原因很好：你可能可以配置你的工具，當引入一個新的失敗測試時不要尖叫，並且只能在迴歸時投訴。

與往常一樣，我會領你到維基百科的generic introduction on the topic。更詳細的，相當有名的資源將是文章從Martin Fowler

Answer 4

只需保持您的測試和代碼在單獨的目錄，然後您可以簽出一個版本的測試和另一個代碼。

話雖這麼說，在多開發環境中，你通常不希望在代碼檢查在測試失敗。

我也質疑這樣做的動機是什麼？如果首先「執行」失敗的測試，那麼我會指出你來自TDD（推廣）的父親this comment。

Answer 5

「在某些情況下，您可能添加已經通過測試，但他們會比發展更驗證。」

在TDD中，你總是注意一個測試失敗，然後讓它通過，以便你知道它的工作原理。

正如您看到的，有時你想明確地描述由代碼覆蓋您已經編寫但是從被測類之外認爲當是類的一個單獨的功能特性。在那種情況下，測試會通過。

但是，仍然看着測試失敗。

要麼寫有明顯的失敗斷言測試，然後修復斷言，使其通過。或者，暫時中斷代碼並觀察所有受影響的測試失敗，包括新測試。然後修復代碼以使其重新工作。

Answer 6

如果您在編寫失敗的測試之後再測試，然後再次傳遞時，您應該在以後能夠在測試失敗的位置創建分支。

然後，您可以添加更多的測試，驗證他們也失敗了，git commit，git merge，然後運行當前的代碼基礎的測試，看看你已經做的工作​​會導致測試通過，或者如果您現在需要做更多的工作。