问每个方法只有一个测试类？

EN

我个人的观点是:您将以一种逻辑且易于维护的方式创建测试类。现在，如果你有两个紧密相关的方法，我不明白你为什么要创建两个类。还有一件事要考虑你有多少测试方法。你不会想要有一个庞大的测试类。最终，您还必须维护测试类，因此要像对待常规代码库一样对待它们。

为每个生产类创建一个测试类的主要优点是它简单易懂。如果你有Foo，你肯定知道Foo的所有单元测试都可以在FooTest中找到(或者不管你的命名习惯怎么叫它。您正在遵循单元测试类名的命名约定，不是吗？)

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

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

我不明白为每个方法引入测试类的原因。老实说，我从来没有见过这种测试策略。

当然，如果你有理由的话，你可以拆分你的测试类。您可以在单独的帮助器类中提取测试的公共部分。在某些情况下，测试类之间的继承也是合理的。

测试代码和生产代码没有区别。你的测试代码应该是清晰的，可读的和可维护的。我认为“每个方法一个测试类”的思想会毁了它。