因为今天我已经使用该模式为每个类创建一个测试类。 例如，带有方法“DoSomething”和“DoNothing”的类“Foo”有一个名为“FooTests”的测试类。每种方法一个测试类？
现在我听说过为每种方法创建一个测试类。对于前面的例子，这意味着我创建了两个名为“DoSomethingTests”和“DoNothingTests”的新类，而不是类“FooTests”。
这是一个常用的模式，我应该切换到这一个，还是这是一个反模式？
感谢您的帮助。
我的个人意见是这样的：你将以这样一种逻辑性和易于维护的方式创建测试类。现在，如果你有两个非常密切相关的方法，我不明白你为什么要创建两个类。还有一件事要考虑你有多少测试方法。你不想有一个巨大的测试课。最终你还必须维护测试类，所以请把它们当作你的常规代码库。
我看不出为每种方法引入测试类的原因。老实说，我从来没有见过这种测试策略。
当然，如果你有理由，你可以分解你的测试课程。您可以在分开的助手类中提取测试的公共部分。在某些情况下，测试类之间的继承也是合理的。
测试代码和生产代码没有区别。您的测试代码应该清晰，易读且可维护。我认为“每个方法一个测试类”的意识形态可以毁掉它。
我认为这是所有关于何时应用这样的事情。我会说，一般来说，你应该而不是是每个测试方法创建一个测试类。我建议在单个测试类中使用相同功能的分组方法（例如，单个类中的方法）。然而，例外可能是一个非常复杂的方法，需要数十次测试来验证其行为。在这种情况下，单个测试类可能会有用。尽管如此，您必须小心创建异常，因为这会使代码的结构不太明显。
为每个生产类创建一个测试类的主要优点是它简单易懂。如果你有Foo，那么你肯定知道Foo的所有单元测试总是可以在FooTest中找到（或者你的命名约定称之为命名惯例，你是按照单元测试类名的命名惯例，不是吗？）
为了便于阅读，我建议您的团队定义一个帮助识别测试的命名约定。例如，我可能会列出其中一个测试FooTest::DoSomething_ensureNullPointerThrowsException()。这样，读者不仅知道它是对Foo::DoSomething()的测试，但他们也知道它正在测试空指针异常。一般来说，如果某些东西看起来“错”或“难以做到”;如果你认为做不同的事情会更容易些，因为你的项目似乎并没有像其他人那样做;这通常是由于违反了一个或多个面向对象设计原则。深究根本原因：为什么我在X问题上挣扎？为什么有人希望每种生产方法都需要一个测试课程？每种方法是否有一百个测试，开发人员认为一个更改会使他们更好地组合在一起？真正的原因可能是他的方法责任过大，或者过于复杂。如果他的方法更简单，他可能会发现他每种方法只需要5或10次测试。