我前段时间写过有关OOP中的反模式的文章 。 现在该写单元测试反模式了，因为它们也存在，并且有很多。 我将尝试在列表中包括我知道的每个示例。 如果您认识其他任何人，请通过请求请求将其添加，或在下面发表评论。 对于每个反模式，如果不是我的，我将尝试提及它的发现位置。 请记住，如果我在某处找到它，并不一定意味着它是在那发明的。 如果发现错误，请发表评论。
杜鹃 1 （又称陌生人3 ）。 这是一种测试方法，它位于同一单元测试中，但实际上并不属于该单元测试。
按方法测试 1 。 尽管测试和生产类之间的一对一关系是一个合理的起点，但是测试和生产方法之间的一对一关系几乎总是一个坏主意。
肛门探针 2 。 必须使用不健康的方式执行其测试的测试，例如使用反射读取私有字段。
连体双胞胎 2 。 测试称为单元测试，但实际上是集成测试，因为被测系统和测试之间没有隔离。
幸福的道路 （又名对所有赔率3 ，骗子3的成功）。 这些测试始终走在快乐的道路上（即预期的结果），而无需测试边界和异常。
慢戳 3 。 运行非常慢的单元测试。 开发人员启动测试时，他们有时间去洗手间，抽烟，或者更糟糕的是，在一天结束之前回家进行测试。
巨人 3 。 尽管可以有效地测试被测对象，但它可以跨越数千行并且包含许多测试用例的单元测试。 这可以表明被测系统是上帝对象。
嘲讽 3 。 有时嘲笑会很好并且很方便。 但是有时，开发人员可能会迷失自己去模仿未经测试的内容。 在这种情况下，单元测试包含太多的模拟，存根和/或伪造品，以至于根本没有对被测系统进行测试，而是从模拟返回的数据正在被测试。
检查员 3 。 为了达到100％的代码覆盖率而违反封装的单元测试，但是对对象中发生的事情了解得非常多，以至于任何重构的尝试都会破坏现有的测试，并要求任何更改都应反映在单元测试中。
慷慨的剩菜 3 （又名链帮 ， 湿地板 ）。 一个实例，其中一个单元测试创建了保留在某处的数据，而另一个测试出于自己的vious回目的重用了数据。 如果“生成器”是随后运行的，或者根本不运行，则使用该数据的测试将完全失败。
本地英雄 3 （又名“隐藏依赖项”，“操作系统推广者”，“ 观望者” ，“ 环境破坏者” ）。 为了运行，该测试用例依赖于特定于其编写的开发环境的东西。 结果是测试通过了开发箱，但在有人尝试在其他地方运行它时失败。
Nitpicker 3 。 单元测试仅在只对其中的一小部分感兴趣时才比较完整的输出，因此测试必须与其他不重要的细节保持一致。
秘密守望者 3 。 乍一看，由于没有断言，因此似乎没有进行任何测试，但是正如他们所说，“细节决定成败”。 该测试实际上是在发生事故时依赖于引发异常，并且期望测试框架捕获该异常并将其作为故障报告给用户。
道奇 3 。 单元测试具有许多针对次要（并且可能易于测试）副作用的测试，但从未测试核心所需的行为。 有时，您可能会在与数据库访问相关的测试中找到此方法，该测试中调用了一个方法，然后该测试从数据库中选择并针对结果运行断言。
劳德茅斯 3 。 单元测试（或测试套件），即使通过测试，也会通过诊断消息，日志记录和其他杂项混乱控制台。
贪婪的守望者 3 。 捕获异常并吞没堆栈跟踪的单元测试，有时将其替换为信息较少的失败消息，但有时甚至只是记录日志（请参阅Loudmouth）并通过测试。
音序器 3 。 单元测试取决于断言期间以相同顺序出现的无序列表中的项目。
枚举器 3 （又名无名测试 ）。 单元测试，其中每个测试用例方法名称仅是一个枚举，例如test1 ， test2 ， test3 。 结果，测试用例的意图不明确，唯一可以确定的方法是阅读测试用例代码并祈求清晰。
Free Ride 3 （又名Piggyback ）。 而不是编写新的测试案例方法来测试另一个功能，而是在现有测试案例中使用新的断言。
设置 3 过多 （又名Hen母亲 ）。 为了进行测试，需要进行大量工作才能进行的测试。 有时，使用数百行代码来设置一个测试的环境，其中涉及多个对象，由于所有设置的“噪音”，因此很难真正确定要测试的内容。
线打手 。 乍一看，这些测试涵盖了所有内容，并且代码覆盖率工具可以100％确认它，但是实际上，这些测试只是对代码进行了编码，而没有进行任何输出分析。
四十英尺杆测试 （ 请参阅 ）。 由于这些测试过于接近他们要测试的类，因此它们之间的距离很远，被无数的抽象层和他们正在检查的逻辑中的数千行代码分隔开。
有用的链接：
- Spock：由Rob Fletcher 主持并运行
- Boni Garcia的JUnit 5掌握软件测试
- TDD反模式 （James Carr）
翻译自: https://www.javacodegeeks.com/2018/12/unit-testing-anti-patterns-full-list.html
)
