因爲今天我已經使用該模式爲每個類創建一個測試類。 例如，帶有方法「DoSomething」和「DoNothing」的類「Foo」有一個名爲「FooTests」的測試類。每種方法一個測試類？
現在我聽說過爲每種方法創建一個測試類。對於前面的例子，這意味着我創建了兩個名爲「DoSomethingTests」和「DoNothingTests」的新類，而不是類「FooTests」。
這是一個常用的模式，我應該切換到這一個，還是這是一個反模式？
感謝您的幫助。
我的個人意見是這樣的：你將以這樣一種邏輯性和易於維護的方式創建測試類。現在，如果你有兩個非常密切相關的方法，我不明白你爲什麼要創建兩個類。還有一件事要考慮你有多少測試方法。你不想有一個巨大的測試課。最終你還必須維護測試類，所以請把它們當作你的常規代碼庫。
我看不出爲每種方法引入測試類的原因。老實說，我從來沒有見過這種測試策略。
當然，如果你有理由，你可以分解你的測試課程。您可以在分開的助手類中提取測試的公共部分。在某些情況下，測試類之間的繼承也是合理的。
測試代碼和生產代碼沒有區別。您的測試代碼應該清晰，易讀且可維護。我認爲「每個方法一個測試類」的意識形態可以毀掉它。
我認爲這是所有關於何時應用這樣的事情。我會說，一般來說，你應該而不是是每個測試方法創建一個測試類。我建議在單個測試類中使用相同功能的分組方法（例如，單個類中的方法）。然而，例外可能是一個非常複雜的方法，需要數十次測試來驗證其行爲。在這種情況下，單個測試類可能會有用。儘管如此，您必須小心創建異常，因爲這會使代碼的結構不太明顯。
爲每個生產類創建一個測試類的主要優點是它簡單易懂。如果你有Foo，那麼你肯定知道Foo的所有單元測試總是可以在FooTest中找到（或者你的命名約定稱之爲命名慣例，你是按照單元測試類名的命名慣例，不是嗎？）
爲了便於閱讀，我建議您的團隊定義一個幫助識別測試的命名約定。例如，我可能會列出其中一個測試FooTest::DoSomething_ensureNullPointerThrowsException()。這樣，讀者不僅知道它是對Foo::DoSomething()的測試，但他們也知道它正在測試空指針異常。一般來說，如果某些東西看起來「錯」或「難以做到」;如果你認爲做不同的事情會更容易些，因爲你的項目似乎並沒有像其他人那樣做;這通常是由於違反了一個或多個面向對象設計原則。深究根本原因：爲什麼我在X問題上掙扎？爲什麼有人希望每種生產方法都需要一個測試課程？每種方法是否有一百個測試，開發人員認爲一個更改會使他們更好地組合在一起？真正的原因可能是他的方法責任過大，或者過於複雜。如果他的方法更簡單，他可能會發現他每種方法只需要5或10次測試。