TDD入門？

Question

我們正處於嘗試實施TDD的初始階段。我演示了Visual Studio Team System代碼覆蓋/ TDD工具，團隊對可能性感到興奮。目前我們使用Devpartner進行代碼覆蓋，但是我們想要消除它，因爲它很昂貴。我們在TDD方面的經驗非常有限，並且希望確保我們不會走錯方向。目前我們正在使用SourceSafe進行源代碼管理，但將在大約一年時間內遷移到Team System。

我可以告訴你我們的應用程序非常以數據爲中心。我們有大約900個表格，6000個存儲過程和大約45GB的數據。我們有很多基於用戶數據和系統中不同費率的計算。我們的許多代碼也是基於時間的（計算當前日期的利息）。其中一些計算非常複雜且非常密集（只有少數人知道其中一些細節）。

我們希望實施TDD解決質量保證問題。許多開發人員被迫修復了他們不熟悉的領域中的錯誤並最終導致了一些問題。也有開發人員幾乎不敢接觸的區域，因爲代碼被系統中的所有內容所使用。我們想要緩解這個問題。

我害怕，因爲我們的代碼是如此以數據爲中心，所以實現TDD可能比大多數系統稍微複雜一些。我試圖想出一個可以呈現給管理層的遊戲計劃，但我希望不會陷入TDD初學者的一些錯誤。同樣，如果Team System中的工具/設施使TDD更加完善，那麼這很好，但我們不希望等待Team System開始。

我們問的第一個問題是我們應該從visual studio中的工具開始？我讀過的帖子是人們抱怨Visual Studio中的內在工具（需要創建一個單獨的項目來創建您的測試），但Visual Studio中的工具的一件事是他們是免費的，整合是好的。如果我們決定使用XUnit，MBUnit或NUnit等其他途徑，那麼我們很可能會有一些可能的顯着成本：

1）如果我們想要IDE集成（未提及我們的大部分代碼是VB.Net）
--- TestDriven.Net or Resharper or ?????

2）如果我們想代碼覆蓋率
--- NCover（似乎是相當昂貴的它的功能）

此外，我已經看到了在Visual Studio 2010中演示了喜歡做的事輸入的能力一些很酷的功能測試（在表單上輸入數據）或記錄用戶完成的操作，然後將其輸入單元測試以重現問題。

此外，雖然我還不太瞭解嘲笑對象的概念，但我知道很多人都覺得這是必須的。問題是，所有的模擬框架能否插入Visual Studio的TDD（MSTEST）版本？

我向管理層建議，我們應該增加回歸測試（新開發或發現錯誤），但不要試圖通過我們所有的代碼並進行單元測試。這將是項目太大的方式。

無論如何，我將不勝感激任何人的幫助。

Answer 1

首先要做的就是讓這本書：

Working Effectively with Legacy Code

對於這樣一個大型項目，閱讀和內在化。 TDD在數據驅動的應用程序上已經夠用了。在遺留的一個，你需要一些認真的計劃和努力。在我看來值得，但它仍然是一個巨大的曲線。

Answer 2

1）我使用TestDriven.Net，我喜歡它這麼一個+1從我爲
2）代碼覆蓋率是有用的，當心中的右框架想過：
高代碼覆蓋率不併不一定意味着高品質的單元測試，但...
高品質的單元測試，是否意味着高的代碼覆蓋率

我只用NCover，所以不能推薦的替代品。

關於嘲笑 - 一旦你掌握了它的內容以及它對你的真正意義，你就會看到它提供的好處。也就是說，它意味着您不依賴於您正在測試的代碼與外部依賴項的集成，並且還有助於減少文本執行時間（例如，嘲笑數據訪問層可防止與數據庫之間的昂貴交互）。在我看來，這是一個很重要的因素，就好像測試需要很長時間才能運行一樣，如果這意味着他們必須等待太久，人們纔會開始不用打擾他們！我使用NUnit，它支持內置的mock。

將TDD方法連接到持續集成環境（例如CruiseControl.NET），並且您擁有非常強大且高效的設置。在開始進行TDD /單元測試時，我總是建議爲從現在開始編寫的代碼編寫測試，而不是過多地關注爲舊版/現有代碼編寫測試。一般來說這樣做很難，而且時間上更加昂貴，特別是如果代碼在人們心目中是舊的/不新鮮的話！

更新：要遠一點，說明我的最後一點響應羅伯特的評論...

當你試圖站起來，與TDD /單元測試運行，並獲得新的動力與整個團隊，你希望儘可能的積極和富有成效。在這個初始階段，沒有改變的舊代碼的編寫測試與新代碼相比是昂貴的，因爲代碼不是新鮮的，它的精確錯綜複雜性很可能不得不重新編譯，而不一定由原始程序員編寫。再加上事實證明你很難證明業務是合理的，花費重新訪問舊代碼爲他們編寫測試所需的時間，而不是開發新的功能/修復真正的錯誤/問題。

它可以成爲一種負面體驗 - 開發人員負責爲他知道/記住的舊代碼編寫測試任務時會發現執行起來更加困難，因此他們的第一次體驗不是積極的。在這種情況下你也需要小心，因爲你可能會以弱測試結束，這會給你錯誤的信心。根據我的經驗，絕對重要的是每個人都能從中獲得積極的開端，否則其中的信心/動機會消失，最終結果會更糟糕。

我是不是實際上說你不應該爲遺留代碼添加測試 - 我自己當我在或沒有任何測試的舊代碼中進行測試以改進測試覆蓋率和質量。不同之處在於，我已經加入了這個過程，一個「信徒」。這是它的早期階段，這是關鍵...因此，我的觀點是，在開始時不會過分關注遺留代碼太多。

Answer 3

那麼，我想首先建議您引入一家瞭解TDD的諮詢公司來幫助您的團隊開始工作。如果團隊中沒有任何熟悉TDD，單元測試，模擬框架等的人，這一點尤其重要。我不確定管理層或團隊已經擁有多少買入，因爲您可能因爲聘請專家幫助您採取這些第一步可能會阻止的錯誤而想要第一次嘗試失敗。

無論如何，我會建議你從小開始，選擇一個不是特別大的新項目。即使是較大項目的一小部分也可以工作。將此作爲讓團隊熟悉TDD並向管理層表明其可行的地方。然後，一旦團隊更精通，你可以選擇更大的項目。至於遺留代碼，我建議在看這本書：

修改代碼的工作，邁克爾羽毛

而且我一定會建議採取一看這本書：

單元測試，羅伊的

藝術Osherove

它可能不是一本TDD書，但它是瞭解單元測試，嘲諷框架的好書，它甚至包含了關於遺留代碼的一章。此外，它還提供了一些關於如何讓團隊和管理層進行購買的建議。它談論了一些關於TDD，集成測試，組織代碼庫以及廣泛討論如何進行良好單元測試的內容。總之一個偉大的閱讀。

希望這會有所幫助。

Answer 4

100贊成有效地工作與遺產代碼建議由Yishai。我還建議您使用.NET的Pragmatic Unit Testing in C# with NUnit（儘管我假設C＃）。這對於教授單元測試的基礎知識非常有用，爲從此開展工作提供了堅實的基礎。

Answer 5

不要急於和看在上帝的份上不要試圖強迫開發者做TDD。否則 - 你會得到凌亂的低質量'測試'，這將在幾個月後被刪除，開發人員將不會再想聽到有關TDD的信息。

最重要的TDD要求 - 好知道如何編寫測試（很明顯爲什麼）。

第二個要求 - 好使用過的技術知識。
這是因爲如果很難編寫任何代碼，在頭部設計代碼將是不可能的。

使用過的工具其實並不重要。

P.s.大量的遺留代碼和以數據爲中心的應用程序=>是一個很好的災難模式。

Answer 6

幾年來，我意識到並且在編寫單元測試時涉獵很深。什麼讓我真正參與單元測試是當我開始在一個開源項目上進行測試的時候。這讓我非常震驚，我寫軟件的方式「處於歷史的錯誤一邊」。

您提到了許多工具，這些工具的廣告功能讓您感到興奮，並且想知道如何將它們放在一起。我認爲這些問題通過Addison-Wesley的「xUnit Test Patterns」得到了很好的解決（http://xunitpatterns.com/）。這本書讓我把過去所有我讀過的工具和技術彙集在一起​​。

這本書可能會更好地服務於那些也欣賞其他書籍，如四人幫的設計模式，重構和重構模式的讀者。這些書也很棒，雖然他們在閱讀完後我的編碼沒有如此直接的變化。 XUnit測試模式的介紹反映了書籍的風格。起初它們很難閱讀，因爲它們傾向於在任意方向上交叉參考章節。我認爲他們非常堅實。

GoF呈現模式類別 - 創作型，結構型和行爲型。這些類別可用作關聯和對比所解釋模式的一種方式。通過將測試設計模式與單元測試的典型生命週期相關聯，XUnit測試模式還將單元測試可用的一系列技術編織在一起。同樣的步驟也用於關聯和對比用於構建單元測試的各種工具。

這將有助於高層次的觀點，並進入實際實施。

我唯一對XUnit測試模式的批評是他們用多少文本批評NUnit。 NUnit是一個很好的編程程序，它的作者信譽NUNit在我認爲將成爲一本經典書籍時非常突出地提到。

Answer 7

關於入門，我還建議閱讀福勒的Refactoring。第一章介紹了引入測試意味着什麼，然後安全地引入變化（儘管這裏強調的是保持行爲的變化）。此外，this談話描述了一些可以幫助提高代碼可測試性的做法。 Misko Hevery也有this編寫可測試代碼的指南，其中總結了這個話題。

從您的描述中，聽起來好像您要測試系統的核心部分 - 這些部分具有很多依賴性，其中的變化很可怕。取決於數據訪問與業務邏輯的分離程度，您可能需要重新考慮代碼更易於測試的狀態 - 可以輕鬆快速地實例化一組測試數據，以便驗證隔離的邏輯。這可能是一項很大的工作，如果這裏的更改不經常發生，並且代碼基礎已得到充分驗證，則可能不值得付出努力。

我的建議是實事求是，並且利用團隊的經驗來找到最容易添加測試的地方，從而增加價值。我認爲有許多重點單元測試是提高質量的最佳方法，但使用集成或場景測試在更高層次上測試代碼可能更容易一些，當然在一開始就是如此。通過這種方式，您可以儘早發現核心系統中的重大故障。清楚你的測試涵蓋的內容。情景測試將涵蓋很多代碼，但可能不會顯示細微的錯誤。

從SourceSafe轉到團隊系統是一大步，有多大取決於你想在團隊系統中做多少。我認爲使用Visual Studio內置的測試框架可以獲得很多價值。例如，作爲第一步，您可以爲核心系統/核心用例實現一些基本測試套件。開發人員可以在Visual Studio中自行運行並在簽入之前自行運行這些套件。這些套件可以逐步擴展。稍後，當您獲得TFS時，您可以在簽入時運行這些套件並將其作爲自動構建過程的一部分。無論具體工具如何，您都可以遵循相似的路徑。

從一開始就明確指出，維護測試代碼存在開銷，並且設計良好的測試可以分紅。我已經看到了測試複製粘貼然後稍微編輯的情況。像這樣的測試代碼重複可能會導致測試代碼的行數急劇增加，這些測試代碼在實現小的產品代碼更改時需要維護。這種麻煩可能會削弱測試帶來的好處。

Visual Studio 2008將只顯示塊覆蓋率，但代碼分析還會給出其他度量，如每個程序集/類/方法的複雜度。通過測試獲得高塊覆蓋率當然很重要，並且可以讓您輕鬆識別完全未經測試的系統區域。

但是，我認爲重要的是要記住，高塊覆蓋率只是對測試有效性的簡單測量。例如，假設您編寫一個類來清除文件歸檔並保留5個最新的文件。然後你寫一個測試用例，檢查你是否從10個文件開始，然後運行你剩下的purger。一個通過測試的實現可以刪除最新的文件，但可以很容易地給出100％的覆蓋率。該測試僅驗證1個要求。