我认为这张图片无需多言，我将告诉您我遇到的最糟糕的测试代码是什么样子，以及它是如何工作的。将介绍的反模式，会按恶心程度🤮进行评级。恶心程度🤮代表糟糕，到🤮🤮🤮代表完全不可原谅。
当前的状况是：整个测试代码大约有 10 个文件。其中 9 个是“合理的”，第10个是一场噩梦：它有大约 3000 行代码，总共约有 80 个测试用例。大约 95% 的测试都是这个文件。除了测试用例之外，测试用例中使用的所有工具都分散在这个文件中。
混合测试用例
恶心程度：🤮
文件包含了许多不同类型的测试，从单元测试到集成测试，再到端到端测试。有些测试非常难以确定其测试类型，比如有些单元测试通过运行系统的主要部分来测试特定的小功能，而在其他情况下，通过调用系统的一系列内部功能来执行重要的端到端测试。
测试用例编号
恶心程度：🤮🤮🤮
所有的测试用例名称都进行了编号！所有的测试都采用了TestXX_测试验证内容的形式。
这是一个非常严重的警示信号，当我加入这个项目时，我没有完全理解它的重要性。大约经过两个月的工作后，发现测试之间的编号是为了强制执行顺序，因为如果以其他顺序执行，测试就会失败！这些编号存在是因为这些测试用例之间是相互依赖的。
不用说，当我移动一些测试用例以使这个巨大的文件变得更干净时，我已经通过惨痛的方式了解到了这一点。
如果我想添加一个测试用例，它与其他测试用例的正确排序至关重要。这导致了一个及其荒谬的情况，我需要正确命名测试用例才能使其按正确的顺序运行。因此，如果我希望在 Test34_XXX 和 Test34_YYY 之间运行一个测试用例，我必须将它命名为 Test341_ZZZ，以保持字典顺序的正确性。🤯
匿名测试
恶心程度：🤮
还有一件关于测试名称的事情—其中一些是匿名的—它们没有说明实际覆盖的内容，比如：test19_requirement_59_passes或大家比较喜欢使用的形式*test87_process_works*. 有些测试用例只有当我引入导致它们失败的更改时，我才了解它们测试的内容，过程中会迫使我去做一些调查工作以弄清楚它们的目的。
没有断言
恶心程度：🤮🤮🤮
有些测试并未以断言结束。你完全可以问，一个没有断言的测试在做什么?
在这些测试中，顶部有一条注释，指示“用户”去执行某些操作。通常情况下，它可能是类似于“去日志文件中检查是否存在格式为X—Y—Z的日志消息”的指示。
不用说，这并没有说明日志文件的位置，以及如果存在多个日志文件（由于日志轮换配置）应该怎么做。此外，在某些情况下，这些指示可能已经过时，而且自编写“测试”和其指示以来，日志消息可能已经发生了变化。
这些测试显然总是通过的，在项目交接期间没有人告诉我这些测试点，当我添加一个功能时我发现了这些，并且纯粹偶然注意到，有一个测试，其名称表明它测试了与我所实现内容相反的过时行为。显然，它通过了（因为它没有断言）。
我已经删除了这些测试，再也没有回头看过。
复杂而晦涩的输入
恶心程度：🤮
系统的测试输入非常复杂，大多数测试都是基于单个输入文件。除了“刚好足以让测试通过的输入”之外，它包含了什么内容并不清楚。没有人真正记得这个测试文件是如何创建的。每当我们需要更改输入时，我们都会有点心痛。
共享状态的传递
恶心程度：🤮🤮
不仅测试之间存在相互依赖，被测试的系统本身还会在各个测试之间传递一些内部状态。原作者没有在每次测试之前重新创建系统，而是添加了一组方法，使用测试驱动程序把内部状态置为无效。
不清晰的入口
恶心程度：🤮🤮
很少有测试以特定顺序调用内部函数—确切地说，测试的入口是不清楚的。事实证明，所有这些被调用的函数分散在不同的类中，它们会影响一些内部共享状态，最终对其预期的终态进行测试。
