我做了TDD，並且在組織我的單元測試方面我一直相當寬鬆。我傾向於從代表下一個故事或功能塊的文件開始，並編寫所有單元測試來完成這項工作。當然，如果我正在引入一個新類，我通常會爲該類創建一個單獨的單元測試模塊或文件，但是我不會將這些測試本身組織到任何更高級別的結構中。結果是我編寫代碼的速度很快，而且我相信我的實際程序結構合理，但單元測試本身很「雜亂」。特別是，它們的結構傾向於重述發展過程的系統發育。有時候我認爲自己在測試中懶惰的代碼中懶惰。你如何在TDD中組織你的單元測試？
這個問題有多大？誰在這裏不斷重構和重組他們的單元測試，試圖改善他們的整體結構？任何提示爲此？測試的整體結構應該是什麼樣子。
（請注意，我沒有那麼多，詢問這裏的「有多少每個功能的斷言」的問題問：How many unit tests should I write per function/method?我說的大局觀）
將你的測試在2臺：
功能測試是每個用戶的故事。單元測試是每課。前者檢查你是否真的支持這個故事，後者是練習並記錄你的功能。
功能測試有一個目錄（包）。單元測試應該與他們運行的功能緊密結合（因此它們是分散的）。當你移動&重構你的代碼時，你將它們移動並重構它們。
我寫一個單元測試類各類，並保持測試類與被測試類在同一個包結構中。
在每個測試班裏面，我沒有太多的組織結構。每個測試中的每個公共方法都只有少數幾個方法，所以我從來沒有發現任何問題。
我嘗試將單元測試視爲一個項目。與任何項目一樣，組織應遵循一些內部邏輯。它不一定是特定的或正式的定義 - 任何你感到舒服的事情都可以，只要它保持你的項目組織良好和清潔。
因此，對於單元測試，我通常要麼遵循主項目代碼結構，要麼專注於功能區域（有時在情況需要調用時）。
在一個堆離開他們是你想象的混亂和難以維持
對於軟件中的每個類，我都維護一個單元測試類。單元測試類與被測試的類遵循相同的包層次結構。
我把我的單元測試代碼保存在一個單獨的項目中。有些人還喜歡將他們的測試代碼保存在同一個項目下，稱爲'test'。你可以按照你感覺舒服的方式進行。
不太重要的部分是組織測試。
我首先將測試放入與測試類相關的類中，com.jeffreyfredrick.Foo測試com.jeffreyfredrick.FooTest。但是如果這些類的某些子集需要不同的設置，那麼我會將它們移到他們自己的測試類中。我把我的測試放到一個單獨的源代碼目錄中，但保留在同一個項目中。
更重要的部分是重構測試。
是的，我嘗試重構我的測試，因爲我去。我們的目標是消除重複，同時保持聲明性，易於閱讀。在測試類和測試類中都是如此。在一個測試類中，我可能有一個參數化方法來創建一個測試假（模擬或存根）。我的測試假名通常是測試類中的內部類，但如果我發現需要，我會將它們提取出來供跨測試重用。當它看起來合適時，我還會使用通用方法創建一個TestUtil類。
我認爲重構你的測試對於在大型項目上進行單元測試的長期成功很重要。你有沒有聽過有人抱怨他們的測試過於脆弱或阻止他們改變？您不希望變更某個類的行爲意味着對您的測試進行數十次甚至數百次更改。就像使用代碼一樣，您可以通過重構來實現這一點，並保持測試的清潔。
測試是代碼。
「重演系統發育史」？哇。 – 2008-11-25 15:35:38
@OAB：「哇」不是我會用的單詞。我和下一個人一樣，是一個意大利人的粉絲，但這只是一個巨大的動力。 – raven 2008-12-07 00:53:14