每种方法一个测试类？

Question

从今天开始，我使用该模式为每个类创建一个测试类。 例如，使用方法“DoSomething”和“DoNothing”的类“Foo”有一个名为“FooTests”的测试类。

现在我听说为每个方法创建一个测试类。对于前面的示例，这意味着我创建了两个名为“DoSomethingTests”和“DoNothingTests”的新类，而不是“FooTests”类。

这是一种常用的模式吗？我应该切换到这种模式，还是这种反模式？

谢谢你的帮助。

Answer 1

我的个人意见是：您将以合乎逻辑且易于维护的方式创建测试类。现在，如果你有两个非常密切相关的方法，我不明白为什么你要创建两个类。还有一件事要考虑你有多少种测试方法。你不想拥有一个庞大的测试类。最后，您还必须维护测试类，因此请将它们视为常规代码库。

Answer 2

为每个生产类创建一个测试类的主要优点是它简单易懂。如果你有Foo，你肯定知道Foo的所有单元测试总是可以在FooTest中找到（或者你的命名约定所谓的。你遵循单元测试类名的命名约定，不是吗？）

出于可读性目的，我建议您的团队定义一个有助于识别测试的命名约定。例如，我可能会将其中一个测试命名为FooTest::DoSomething_ensureNullPointerThrowsException()。这样读者不仅知道它是Foo::DoSomething()的测试，而且他们也知道它正在测试空指针异常。

一般来说，如果某些事情看似“错误”或“难以做”;如果您认为以不同的方式做某事会更容易，因为您的项目似乎与其他人的方式不相符;这通常是由于违反了一项或多项OO设计原则。深入了解根本原因：为什么我在问题X上挣扎？为什么有人想要每个生产方法需要一个测试类？每个方法都有一百个测试，开发人员认为更改会使它们更好地组合在一起吗？真正的原因可能是他的方法有太多的责任，或者过于复杂。如果他的方法更简单，他可能会发现他每个方法可能只需要五到十次测试。

Answer 3

我看不出为每种方法引入测试类的原因。老实说，我从未见过这种测试策略。

当然，如果您有理由，可以拆分测试类。您可以在分离的帮助程序类中提取测试的常用部分。在某些情况下，测试类之间的继承也是合理的。

测试代码和生产代码之间没有区别。您的测试代码应该清晰，易读且易于维护。我认为“每种方法一级测试”的意识形态可以毁掉它。

Answer 4

我认为这是什么时候应用这样的事情。我会说，通常你应该不为每个测试方法创建一个测试类。我建议在单个测试类中对具有相同功能的方法（例如，单个类中的方法）进行分组。但是，异常可能是一种非常复杂的方法，需要进行数十次测试才能验证其行为。在这种情况下，单个测试类可能有用。但是，您必须小心创建异常，因为这会使代码的结构变得不那么明显。