language-agnostic - 测试类可以变成 "God object"吗？

Question

我正在为开源 Python ORM 开发后端。该库为每个后端包含一组 450 个测试用例，所有这些都集中在一个巨大的测试类中。

对我来说，对于一个类(class)来说这听起来很多，但我从来没有参与过有 450 个测试用例的项目(我相信这个库有大约 2000 个测试用例，不包括测试每个后端的案例)。我觉得这有点偏高(假设实际上没有任何神奇的数字，你应该分解一些东西)是正确的，还是对一个测试类来说有这么多测试没什么大不了的？

即使没有太多的测试用例，如何重构一个过大的测试类？我关于重构的大部分知识都是关于确保对正在重构的代码进行适当的测试。我从来没有遇到过需要重构测试本身的情况。

编辑:之前，我曾说过这些是单元测试，这并不完全正确。这些更恰本地称为集成测试。

Answer 1

一个类(class)进行 450 次测试听起来很多，但到底有多糟糕取决于它们的组织方式。如果它们都真正独立于彼此和测试类的成员，那可能没什么大不了的 - 除了一定很难找到特定的测试。

另一方面，如果测试类的成员仅被一些测试使用而被其他测试忽略，则它是一个名为 Obscure Test 的 Test Smell，包含诸如 之类的 Root Causes一般夹具 和不相关信息(请注意行话 - 我会回到这里)。

有多种方法可以将测试组织到类中。最常见的模式是每个类的测试用例类、每个功能的测试用例类和每个夹具的测试用例类。

如何构建测试不仅在编写测试时很重要，而且出于可维护性的原因也很重要。仅出于这个原因，我倾向于说重构测试是值得的。在 TDD 中，测试代码库(几乎)与实际代码库一样重要，应该受到同样的尊重。

关于这个主题有一整本书，叫做 xUnit Test Patterns: Refactoring Test Code我怎么推荐都不为过。它包含处理单元测试和 TDD 的完整模式语言，我在这里使用的所有模式名称都源自它。