分离类的单元测试是一种糟糕的做法吗？

Question

我的类通常最多有5-20个方法，这意味着具有单元测试的类有大约双倍的方法(计算dataProviders、setUp、.)

我曾经想过将测试分离到2-3个类中，因为即使我试图遵循单一责任原则，我更喜欢两个测试类，每个类有10个方法，而不是一个有20个方法。

这是个坏习惯吗？？虽然测试类是垂直增长的，但是只在一个类中进行所有的测试会好吗？

Answer 1

要回答具体的问题，绝对有可能将测试分组到多个类是一个很好的决定，当被测试的类设计得很好的时候。

单元测试代码和任何其他代码一样:它应该遵循良好的设计原则(干的、抓取抓取、接吻、实心 )。因为组成测试代码的逻辑通常比域逻辑更简单，所以很多特定点不会出现那么多，但是在编写测试时要记住它们。

在思考你的问题时，可以很容易地想到几个原则：

可读性

理想情况下，一旦编写了测试，您就不必再查看它；但是对于任何代码都可以这样说。现实是，需求会发生变化，所以我们发现自己读的代码比编写代码多得多。即使在尽你最大的努力时，你也会发现你写的测试并不能很好地验证你认为它做了什么，这时你就得回去找出出了什么问题。在一类40-50种测试方法中找到测试方法是很困难的，更不用说命名这些方法的复杂性了，这样就可以很容易地区分它们。

高内聚力

每个测试类(像其他类一样)都应该有一个清晰的焦点。如果您对被测试类的给定方法有很多不同的测试用例，比如当给定的测试验证单个事物时，将这些测试方法放在一个单独的类中，并命名它以反映它的焦点。

Answer 2

与拥有单元测试相比，单元测试的组织方式几乎不重要。

模块或业务代码类是您必须作为一个单元来理解并进一步开发的。这就是我们努力使其连贯、易于理解等的主要原因。测试套件只是一组必须通过的案例，它们之间没有任何特殊的关系。理想情况下，您将不再需要处理它；如果这样做，通常是添加更多与任何其他测试没有特殊关系的测试，并且除了单元测试框架之外，客户端代码从来不调用它们。

因此，与如何组织构成应用程序本身的类相比，如何组织包含单元测试的类的问题要重要得多。无论如何，你不应该把它们当作一个架构良好的宏观结构来处理。

Answer 3

把测试放在一个文件中。通常，对于每个类文件，我都会有一个测试文件。通常在文件名后加上“测试”。

例如，如果有一个名为"Foo“的类，就会有一个相应的"FooTests”文件。这样，对于每个代码文件，代码文件和测试文件之间就有1到1的关系。

这提供了一致性，并使开发人员更容易找到测试并保持最新。测试通常被排除在代码分析/度量之外，所以如果文件很大，它不会损害整个代码健康度量，所以我不认为有一个包含大量单元测试代码的测试文件是不好的形式。