TDD和小型團隊短期項目的單元測試？

Question

TDD對於由多達4人的小團隊完成的小型和短期項目來說是一個很好的方法嗎？這真的是一項有利可圖的工作嗎？

單元測試怎麼樣？ TDD意味着單元測試，但相反。在項目開發生命週期中不時進行單元測試是否足夠，直到合理的代碼覆蓋率？

Answer 1

答案是肯定的！並由於以下原因。 想象你自己下面的場景。您和您的項目團隊已經創建了一個偉大的應用程序，並決定將其投入生產。過了一段時間，一個用戶來找你說：嘿，我發現你的應用程序中有一個錯誤，你可以修復它嗎？當然你會說是修正bug並且用戶很高興。只是過了一段時間，他回來說，很好，你解決了這個問題，但現在有一些工作已經不復存在了，你能修復它嗎？

如果您使用過TDD併爲應用程序進行過單元測試，那麼情況就不會如此。這是因爲您有針對整個應用程序進行的測試。解決了一個bug之後，您只需再次運行單元測試，看看您的「修復」是否會破壞應用程序中的其他任何內容。

這個答案更多的是針對單元測試的使用。以下是關於TDD本身。

什麼TDD讓你作爲一個人做的是思考我要在下面的代碼（對象，類，函數等）。另外我的代碼的邊緣是什麼if/else語句我需要什麼我需要檢查。如果你是由你自己或由20人組成的項目團隊，這並不重要。 TDD的事情是你的思維過程，而不是你項目中的其他人。

Answer 2

如果你正在UnitTesting採取TDD的唯一一小步。但你會從中受益更多。

只是一個例子：TDD定義您首先實施您的測試。這意味着你在開始實施之前想到你想達到的目標。這導致更好的代碼。

Answer 3

對我來說，這並不歸結爲項目是小還是短。 TDD，正確地完成，是關於能夠快速運行一組測試，提供充分的代碼信心。還有很多關於TDD的文章都有助於推動項目的適當設計。

所以，你可能會認爲TDD在小項目和短項目中是最好的，因爲最終你只需編寫代碼就可以讓測試通過，而不需要其他任何東西。因此，降低成本。然後，當您稍後進行更改時，還有對測試和代碼充滿信心的額外好處。

我會做的下一個小點是，許多項目開始小而短。這些臨時解決方案有成爲發展戰略平臺的方法（如果成功的話）。

Answer 4

TDD和單元測試不是彼此替代的。在每個項目中你都應該測試你的代碼，這就是你進行單元測試和集成以及系統測試的地方。

TDD是一種發展模式。像瀑布和其他開發方法一樣，TDD也是一種方法。在TDD中，您有一些基本要求，您可以編寫單元測試以確保需求得到實施和運行。但是當你編寫單元測試時，你會意識到爲了達到主要要求，你需要實現更多的功能和類。所以在這種情況下的單元測試使其他需求更清晰。

假設您需要編寫一個應用程序來打印運行應用程序的計算機的名稱。首先你寫一個單元測試：

[Test] 
public void ProducedMessage_IsCorrect() 
{ 
    AreEqual(BusinessLibrary.ProduceMessage(), System.Environment.MachineName); 
} 

然後你意識到你需要實現ProduceMessage函數。你可以很簡單地實現它，以便單元測試通過。你寫這樣的方法：

public string ProduceMessage() 
{ 
    return "MyComputer"; 
} 

然後你運行測試，它通過。之後，您提交代碼，團隊的其他成員獲取代碼。當他們運行測試時，測試失敗，因爲您在代碼中硬編碼了計算機的名稱。

因此，您的團隊中一些明智的成員將代碼更改爲正確的形式，並繼續前進。

這完全是關於選擇具有TDD經驗的開發人員。至少其中一些應該是我認爲的有經驗的TDD開發人員。

Answer 5

最近我讀了Szymon Pobiega的好博客文章，標題爲If you are not doing TDD…。我真的很希望看看這個。這是因爲我對TDD持懷疑態度，並將其置於開發生命週期的良好習慣中，作爲項目安全性的最終解決方案，除了項目的性質之外。我喜歡這個片段：

當你完全不知道 代碼的形狀時，TDD是最有用的。在這種情況下，您最好不要像代碼 那樣快速破解代碼。而不是一次一小步，每次驗證結果 。理想情況下，做一對。您所做的每一步都允許您 發現更多需要編寫的測試。我喜歡在他的演講中使用的比喻丹 ：這就像游泳與步行在 1.50米深池。你可以一直走路，確保每次你腳上的一隻腳在地面上，或者你可以游泳時更有風險（與地面沒有接觸），但可以讓你移動更快。 TDD就像走路一樣。

他引用Dan North session from NDC 2012。