从今天开始，我使用该模式为每个类创建一个测试类。 例如，具有“DoSomething”和“DoNothing”方法的“Foo”类有一个名为“FooTests”的测试类。
现在我听说要为每个方法创建一个测试类。对于前面的示例，这意味着我创建了两个名为“DoSomethingTests”和“DoNothingTests”的新类，而不是“FooTests”类。
这是一种常用的模式，我应该切换到这个模式，还是这又是一种反模式？
感谢您的帮助。
【问题讨论】：
标签： .net unit-testing testing design-patterns
我个人的看法是：您将以合乎逻辑且易于维护的方式创建测试类。现在，如果您有两个非常密切相关的方法，我不明白您为什么要创建两个类。还有一件事要考虑你有多少测试方法。你不想有一个庞大的测试班。最终，您还必须维护测试类，因此请将它们视为您的常规代码库。
【讨论】：
为每个生产类创建一个测试类的主要优点是简单易懂。如果你有 Foo，你肯定知道 Foo 的所有单元测试总是可以在 FooTest 中找到（或者任何你的命名约定。你正在遵循单元测试类名称的命名约定，不是吗？）
出于可读性目的，我建议您的团队定义一个有助于识别测试的命名约定。例如，我可能将其中一项测试命名为FooTest::DoSomething_ensureNullPointerThrowsException()。这样，读者不仅知道这是对Foo::DoSomething() 的测试，而且他们也知道这是对空指针异常的测试。
一般来说，如果某事看起来“错误”或“难以做到”；如果您认为做一些不同的事情会更容易，因为您的项目似乎与其他人的做法不相符；这通常是由于违反了一项或多项 OO 设计原则。深入寻找根本原因：为什么我在问题 X 上苦苦挣扎？为什么有人想要每个生产方法一个测试类？每种方法是否有一百个测试，并且开发人员认为更改会使它们更好地组合在一起？真正的原因很可能是他的方法责任太大，或者过于复杂。如果他的方法更简单，他可能会发现每种方法只需要五到十次测试。
【讨论】：
我看不出为每个方法引入测试类的原因。老实说，我从未见过这种测试策略。
当然，如果你有理由的话，你可以拆分你的测试类。您可以在单独的辅助类中提取测试的公共部分。在某些情况下，测试类之间的继承也是合理的。
测试代码和生产代码没有区别。您的测试代码应该清晰、可读和可维护。我认为“每个方法一个测试类”的意识形态可能会毁了它。
【讨论】：
我认为这完全取决于何时应用这样的东西。我想说的是，一般来说，您应该不为每个测试方法创建一个测试类。我建议在单个测试类中将具有相同功能的方法（例如单个类中的方法）分组。但是，异常可能是一种极其复杂的方法，需要进行数十次测试才能验证其行为。在这种情况下，单个测试类可能很有用。但是，您必须小心创建异常，因为这会使代码的结构方式变得不那么明显。
【讨论】：