簡體 English 中英

如何開始單元測試或TDD？

[英]How to start unit testing or TDD?

原文 2009-09-02 05:17:37 1 14 unit-testing/ tdd

我讀了很多帖子，說服我應該開始編寫單元測試，我也開始使用依賴注入（Unity）以便更容易進行模擬，但我仍然不太確定在哪個階段我應該開始編寫單元測試和模擬，以及如何或從何處開始。

首選方法是在TDD方法中描述的方法之前編寫單元測試嗎？

單元測試有什么不同的方法或方式嗎？

14 個解決方案

先測試/測試后：

應該注意的是，作為TDD的一部分，“先測試”與設計一樣多（如果不是更多）與單元測試有關。 它本身就是一種軟件開發技術 - 編寫測試結果可以不斷改進設計。

另請注意：如果從單元測試的角度來看TDD有一個顯着優勢，那就是在進行TDD時編寫一個錯誤的測試要困難得多（盡管不是不可能）。 如果您事先編寫測試，它應該總是失敗，因為測試通過所需的邏輯尚不存在。 如果你之后編寫測試，邏輯應該在那里，但如果測試被竊聽或測試錯誤的東西，它可能會通過。

也就是說，如果你以前寫過一個不好的測試，當你期望紅色時你可能會得到綠燈（所以你知道測試是壞的）。 如果你之后寫了一個不好的測試，當你期望一個綠色（沒有意識到不好的測試）時，你會得到一個綠燈。

圖書

實用的單元測試書非常值得一看，Roy Osherove的“單元測試藝術”也是如此。 實用主義書更側重於您可以嘗試查找錯誤的不同類型的測試輸入，而TAOUT涵蓋了更廣泛的主題，如測試雙打，策略，可維護性等。這兩本書都很好; 這取決於你想要的東西。

此外，這里還有一個關於Roy Osherove談論單元測試的鏈接。 這值得觀看（他記錄的一些測試評論視頻也是如此，因為他指出了各種問題和注意事項以及原因）。

怎么開始

沒有比編寫代碼更好的了。 找一個相當簡單的類，但沒有引用其他內容。 然后，開始編寫一些測試。

總是問自己“我想嘗試用這個測試來證明什么？” 在你編寫之前，給它一個合適的名稱（通常涉及被調用的方法，場景和預期結果，例如在堆棧上：“Pop WhenStackIsEmpty ThrowsException”）。

想想你可以投入的所有輸入，可能產生有趣結果的不同方法組合等等。

如果您對單元測試感到好奇，那么最好的方法是嘗試它。 您可能會首先開始編寫集成測試，但這很好。 當它們看起來難以維護或編寫太多工作時，請閱讀更多關於有哪些類型的測試（單元，功能，集成）並嘗試了解其中的差異。

如果你有興趣從TDD開始，鮑勃叔叔是一個很好的來源。 Particalulary this 。

更多關於單元測試

確保您獲得一致的測試結果。 重復運行相同的測試應該始終如一地返回相同的結果。

測試不應該要求配置。

測試順序無關緊要。 這意味着部分測試運行可以正常工作。 此外，如果您牢記這一設計理念，它可能有助於您的測試創建。

請記住，任何測試都比沒有測試好。 在編寫良好的清潔單元測試時可以找到困難，這些測試可以簡化創建和維護。 測試框架越難，使用它就越反對。 測試是你的朋友。

在C＃和visual studio中，我發現以下過程非常有用：

認為！ 做一個小的前期設計。 您需要清楚地了解您需要哪些類以及對象應如何相互關聯。 只關注一個類/對象（您要實現的類/對象）和一個關系。 否則你最終會有一個太重量級的設計。 我常常在一張備用的紙上畫出多個草圖（只有幾個方框和箭頭）。
在生產代碼中創建類並對其進行適當命名。
選擇要實現的類的一種行為，並為其創建方法存根。 使用visual studio創建空方法存根是件小事。
為它寫一個測試。 因此，您需要初始化該對象，調用該方法並生成一個斷言來驗證結果。 在最簡單的情況下，斷言需要生產代碼中的另一個方法存根或屬性。
編譯並讓測試運行器顯示紅色條！
在生產代碼中編碼所需的行為以查看綠色條。
轉到下一個行為。

對於這個過程，有兩件事非常重要：

你需要一個清晰的圖片你想要什么以及類/對象應該是什么樣子。 至少花一些時間。
考慮類/對象的行為。 這將使測試和生產代碼以行為為中心，這是一種考慮類/對象的非常自然的方法。

首先測試還是先測試？

我發現將測試改裝到現有的生產代碼通常更難。 在大多數情況下，當需要初始化被測對象時，這是由於與其他對象的糾纏不清。 TDD通常會避免這種情況，因為您希望盡可能少地在測試用例中初始化對象。 這將導致非常松散的耦合。

當我改進測試時，必須繁瑣的工作是初始化測試對象的任務。 由於糾結的依賴性，斷言也可能是很多工作。 為此，您需要更改生產代碼並破壞依賴關系。 通過正確使用依賴注入，這應該不是問題。

是的，執行TDD的首選方法是首先編寫測試（正如名稱Test-Driven Development所暗示的那樣）。 當你開始使用TDD時，很難知道從哪里開始編寫測試，所以我建議對它采取務實態度。 畢竟，我們工作中最重要的部分是提供工作代碼，而不是如何制作代碼。

因此，您可以從為現有代碼編寫測試開始。 一旦你了解了單元測試的結構，哪些看起來做得不錯，哪些看起來不那么神，那么你會發現更容易深入到測試優先的方法。 我發現隨着時間的推移，我首先在更大程度上編寫測試。 隨着經驗的增加，它變得更加自然。

史蒂夫桑德森有一篇關於TDD最佳實踐的精彩文章。

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

此外，還有很多關於做ASP.net mvc項目的教程，討論了很多TDD原則（如果你不介意沿途學習ASP.net MVC） http://www.asp.net/learn/ mvc-videos /在頁面底部查找“店面”系列。

最近MOQ似乎是熱門的模擬框架，你可能也想研究它

總之，嘗試編寫一個測試來驗證您嘗試歸檔的內容，然后實現代碼以使其工作。

這種模式被稱為Red - Green - Refactor。 還要盡力減少依賴關系，以便測試可以專注於一個組件。

就個人而言，我使用Visual Studio單元測試。 我不是鐵桿TDD開發者，但我喜歡做的是：

創建一個新項目並根據系統設計定義一些基本類（這樣我至少可以獲得一些智能感知）
創建一個單元測試項目並開始編寫單元測試以滿足我試圖實現的功能。
讓他們失敗
讓他們通過（實施）
重構
重復，嘗試使測試更嚴格或創建更多測試，直到我感覺它堅實。

我也覺得在現有的代碼庫中添加功能非常有用。 如果要添加一些新功能，首先要為要添加的內容創建單元測試，逐步執行代碼以查看必須更改的內容，然后再進行TDD過程。

選擇一個小的非關鍵應用程序並使用TDD實現它。 起初，新的思維方式會讓人覺得奇怪，但也許經過一兩個星期的練習后，感覺很自然。

這是一個教程應用程序（在分支“教程”中），它顯示了要編寫的測試類型。 在該教程中，您編寫代碼以傳遞預定義的測試用例，以便您進入節奏，然后再編寫自己的測試。 README文件包含說明。 它是用Java編寫的，但您可以輕松地將其應用於C＃。

在 mocks和依賴注入之前，我將采用TDD，測試優先開發。 嗯，模擬可以幫助你更好地隔離你的單位 - 從而做更好的單元測試 - 但在我看來，模擬和DI是更高級的概念，可能會干擾首先編寫測試的清晰度。

模擬和DI都有它們的位置; 它們是您工具箱中的好工具。 但它們比典型的新手測試更復雜，更先進。 然而，首先編寫測試就像聽起來一樣簡單。 所以它更容易接受，它本身就很強大（沒有模擬和DI）。 你會早起，勝更容易通過一次先寫免費模擬測試，比試圖開始嘲笑，和 TDD 和 DI所有。

從測試優先開始; 當你對它很滿意的時候，當你的代碼告訴你需要嘲笑時，那就去嘲笑吧。

我曾為那些過度進行單元測試/集成測試的公司和那些做得太少的公司工作過，所以我覺得我在兩者之間有很好的平衡。

我會推薦TDD - 測試驅動開發。 這可確保您獲得良好的覆蓋率，但同時也會將注意力集中在正確的位置和問題上。

因此，對於每個新開發項目，您要做的第一件事就是編寫單元測試 - 即使您沒有單一的測試類。

想想你正在測試什么。 現在運行測試。 為什么不編譯？ 因為你需要classA。 創建類並運行測試。 為什么不編譯？ 因為它沒有methodA。 編寫方法一並再次運行單元測試。 為什么測試失敗？ 因為methodA沒有實現。 實現方法A並運行測試。 為什么會失敗？ 因為methodA沒有返回正確的期望值...等

你繼續像開發那樣編寫單元測試，然后最終測試將通過，這部分功能將完成。

延伸史蒂夫弗里曼的答案：戴夫阿斯特爾的書被稱為“測試驅動開發 - 實用指南”。 如果您正在編寫的應用程序類型是GUI應用程序，那么這應該會有所幫助。 我讀過Kent Becks的書，但我無法弄清楚如何用TDD開始一個項目。 Astel的書測試 - 使用故事從頭到尾測試一個完整的非平凡的GUI應用程序。 從TDD開始，它幫助了我很多，它向我展示了在哪里以及如何開始。

測試驅動的開發對於初學者來說可能會讓人感到困惑，我在學習TDD時讀到的很多書都會教你如何編寫計算器類的單元測試，但是對於構建真實世界的應用程序似乎沒什么幫助，更多的是如果我敢說，以數據為中心。對我來說，突破是當我理解什么是行為驅動開發或BDD以及如何從外部開始進行測試時。現在我可以建議您專注於您的應用程序行為並編寫單元測試來驗證它。 TDD和BDD之間存在很多爭論，但我認為在每個級別上編寫良好的自動化測試都會增加價值並編寫它們，我們需要關注行為。

Hadi Hariri在這里有一篇很棒的帖子http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

我還寫了一些關於這個主題的文章，我認為這將有助於理解與TDD相關的所有概念

http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/

http://codecooked.com/different-types-of-tests-and-which-ones-to-use/

使用NUnit在C＃中閱讀語用單元測試。 它具有關於開始編寫睾丸和構造代碼以使其更加單元測試友好的全面信息。

如果您之前沒有編寫過單元測試，那么只需選擇一些類並開始編寫單元測試，然后繼續開發更多的單元測試。

當您獲得經驗時，您可以開始模擬數據庫，例如，使用Unity框架，但是，我建議在進行此跳躍之前簡單地開始並獲得經驗。

一旦您對如何編寫單元測試感到滿意，那么您可以嘗試進行TDD。

我更喜歡KentBeck的方法，這本書在“測試驅動開發實例”一書中很好地解釋了 - Kent Beck。

從你的問題我可以推斷你不確定測試框架的工作 - 選擇正確的測試框架工作對TDD或編寫單元測試（一般）非常重要。

只有TDD的實際問題是“重構”（我們需要重構測試代碼）需要花費大量時間。

我認為Dave Astels的書仍然是最好的介紹之一。 它適用於Java，但您應該能夠翻譯。