测试课可以成为"上帝对象"吗？

Question

我正在开发一个开源Python ORM的后端.该库包含一组450个测试用例,每个后端都被集成到一个巨大的测试类中.

对我来说,这对于一个类来说听起来很多,但我从未参与过有 450个测试用例的项目(我相信这个库有大约2000个测试用例,不包括每个后端的测试用例).我是否正确认为这有点高端(假设没有任何神奇的数字,你应该打破一些东西),或者对于测试类来说,进行如此多的测试并不是一件大事？

即使这不是太多的测试用例,如何重构一个过大的测试类呢？我对重构的大部分知识都是为了确保对要重构的代码进行测试.我从来没有必要处理需要重构的测试本身的情况.

编辑:以前,我曾说过这些是单元测试,但这并不完全正确.这些更恰当地称为集成测试.

Answer 1

一堂课 450 次测试听起来很多，但有多糟糕取决于它们的组织方式。如果它们都真正彼此独立并且独立于测试类的成员，那么这可能不是什么大问题 - 除了很难找到特定的测试之外。

另一方面，如果测试类具有仅由某些测试使用而被其他测试忽略的成员，则这是一种称为“模糊测试”的测试气味，其中包含诸如常规固定装置和不相关信息之类的根本原因（请注意行话 - I'稍后会回到这个）。

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

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

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