单元测试反模式目录

反模式：必须至少存在两个关键要素，才能将实际的反模式与简单的坏习惯，坏习惯或坏主意正式区分开：

• 某些重复的动作，过程或结构模式似乎最初是有益的，但最终会产生比有益结果更多的不良后果，并且
• 重构的解决方案已明确记录在案，并在实践中得到证明，并且可重复。

投票一次您在“野外”看到的TDD反模式太多了。
詹姆斯·卡尔（James Carr）的博客文章以及 有关测试驱动开发yahoogroup的相关讨论

如果您找到了一个“未命名”的人。每个反模式请发表一篇文章，以使投票数有所作为。

我的既得利益是找到前n个子集，以便我可以在不久的将来在午餐会上讨论'em'。

二等公民 -测试代码的重构程度不如生产代码，因为其中包含大量重复的代码，因此难以维护测试。

搭便车/搭载-James Carr，Tim Ottinger
而不是编写新的测试用例方法来测试另一个/独特的功能/功能，而是在现有的测试用例中使用新的断言（及其相应的动作，即来自AAA的Act步骤） 。

快乐之路

该测试停留在令人满意的路径（即预期结果）上，无需测试边界和异常。

JUnit反模式

本地英雄

一个测试用例，它依赖于特定的开发环境才能运行。结果是测试通过了开发箱，但在有人尝试在其他地方运行时失败。

隐藏的依赖

与本地英雄密切相关的单元测试，需要在测试运行之前在某处填充一些现有数据。如果没有填充该数据，则测试将失败，并且几乎没有向开发人员表明它想要什么，或者为什么……迫使他们挖掘大量的代码以查明其使用的数据应该来自哪里。

令人遗憾的是，对于依赖于模糊和变化的.ini文件的古老.dll，它们在任何给定的生产系统上总是不同步，这已经太多次了，更不用说在没有与负责这些dll的三位开发人员进行广泛咨询的情况下在您的计算机上存在了。叹。

链帮

必须按一定顺序运行的几个测试，即一个测试更改了系统的全局状态（全局变量，数据库中的数据），下一个测试依赖于此。

您经常在数据库测试中看到这一点。测试无需在中进行回滚，而是teardown()将其更改提交到数据库。另一个常见的原因是，对全局状态的更改没有包装在try / finally块中，这些块在测试失败时会清除。

嘲弄
有时嘲讽可以很好，和方便。但是有时开发人员可能会迷失自我，无法模拟出未经测试的内容。在这种情况下，单元测试包含许多模拟，存根和/或伪造品，以至于根本没有对被测系统进行测试，而是从模拟返回的数据正在被测试。

资料来源：詹姆斯·卡尔（James Carr）的帖子。

沉默的守望者 -凯利？
如果引发异常，则通过的测试..即使实际发生的异常与开发人员预期的异常不同。
另请参阅：秘密捕手

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}

Inspector
单元测试，它违反封装以达到100％的代码覆盖率，但是对对象中发生的事情非常了解，因此任何重构的尝试都会破坏现有测试，并要求任何更改都应在单元中反映出来测试。

“如何在不公开成员变量的情况下测试我的成员变量…… 仅用于单元测试？”

设置过多 -詹姆斯·卡尔（James Carr）
一种测试，需要进行大量设置才能开始测试。有时，使用数百行代码为一个测试准备环境，其中涉及多个对象，由于所有设置的“噪音”，使得很难真正确定要测试的内容。（来源：詹姆斯·卡尔的帖子）

肛门探针

必须使用疯狂，非法或其他不健康的方式执行测试的测试，例如：使用Java的setAccessible（true）读取私有字段或扩展类以访问受保护的字段/方法，或者必须将测试放入特定的程序包中以进行访问打包全局字段/方法。

如果看到此模式，则被测类将使用过多的数据隐藏。

此代码与The Inspector之间的区别在于，被测类试图甚至隐藏您需要测试的内容。因此，您的目标不是获得100％的测试覆盖率，而是能够测试所有内容。想一想一个只有私有字段，run()没有参数且根本没有getter 的方法的类。没有违反规则的方法就无法进行测试。

Michael Borgwardt的评论：这实际上不是一个测试反模式，它是一种实用主义，可以解决所测试代码中的缺陷。当然，最好修复这些缺陷，但是对于第三方库来说，这可能是不可能的。

亚伦·迪古拉（Aaron Digulla）：我有点同意。也许此条目确实更适合“ JUnit HOWTO” Wiki，而不适合反模式。注释？

没有名字的测试 -尼克·佩洛

为在错误跟踪器中重现特定错误而添加的测试，其作者认为自己的名字不做保证。除了增强现有的缺少的测试外，还创建了一个名为testForBUG123的新测试。

两年后，当测试失败时，您可能需要首先尝试在错误跟踪器中找到BUG-123，以弄清测试的意图。

慢戳

运行非常慢的单元测试。开发人员启动测试时，他们有时间去洗手间，抽烟，或者更糟糕的是，在一天结束之前回家进行测试。（来源：詹姆斯·卡尔的帖子）

亦即不会频繁运行的测试

蝴蝶

您必须测试某些包含随时更改的数据的东西，例如包含当前日期的结构，并且无法将结果固定为固定值。丑陋的部分是您根本不在乎此值。它只会使您的测试变得更加复杂，而不会增加任何价值。

机翼上的蝙蝠会在世界的另一端造成飓风。-爱德华·洛伦兹（Edward Lorenz），《蝴蝶效应》

闪烁测试（来源：Romilly Cocking）

测试偶尔会失败，而不是在特定时间失败，并且通常是由于测试中的比赛条件所致。通常在测试异步内容（例如JMS）时发生。

可能是“ 等待并查看 ”反模式和“ 睡眠者 ”反模式的超集。

构建失败，哦，好了，再次运行构建。-匿名开发人员

等着瞧

运行某些设置代码的测试，然后需要“等待”一段特定的时间，才能“查看”被测代码是否按预期运行。使用Thread.sleep（）或等效方法的testMethod肯定是“等待并查看”测试。

通常，如果测试是测试代码，该代码会在系统外部生成事件，例如电子邮件，http请求或将文件写入磁盘，则可能会看到此消息。

这样的测试也可能是Local Hero，因为它在较慢的设备箱或CI服务器过载时运行失败。

不要将Wait and See反模式与The Sleeper混淆。

夹具共享不当 -Tim Ottinger
测试夹具中的几个测试用例甚至不使用或不需要安装/拆卸。部分是由于开发人员的惯性来创建新的测试夹具...更容易在堆中添加另一个测试用例

巨人

单元测试尽管可以有效地测试被测试对象，但是可以跨越数千行，并且包含许多测试用例。这可以表明被测系统是上帝对象（James Carr的帖子）。

对此的肯定的标志是跨越多行代码的测试。通常，测试是如此复杂，以至于开始包含其自身或片状行为的错误。

当我看到一些闪烁的GUI时，我会相信。
通过其GUI“像真实用户一样”测试应用程序，这是不健康的尝试/痴迷。

通过GUI测试业务规则是一种可怕的耦合形式。如果您通过GUI编写了成千上万的测试，然后更改了GUI，那么成千上万的测试就会失败。
相反，在运行这些测试时，仅通过GUI测试GUI事物，并将GUI耦合至虚拟系统而不是真实系统。通过不涉及GUI的API测试业务规则。-鲍勃·马丁

“您必须了解眼见为实，但也要知道眼见为实。” - 丹尼斯·威特利

卧铺者，又名维苏威火山 -尼克·佩洛

注定要在将来某个特定时间和日期失败的测试。这通常是由于在测试使用Date或Calendar对象的代码时检查边界不正确引起的。有时，如果在一天中的特定时间（例如午夜）运行，则测试可能会失败。

请勿将“卧铺者”与“ 等待并看到 ”反模式混淆。

该代码将在2000年之前被替换 -1960年有许多开发人员

死树

创建存根但未实际编写测试的测试。

我实际上已经在生产代码中看到了这一点：

class TD_SomeClass {
  public void testAdd() {
    assertEquals(1+1, 2);
  }
}

我什至不知道该怎么想。

今天被这个咬了：

湿地板：
测试创建的数据会保留在某处，但测试完成后不会清除。这会导致测试（同一测试或可能其他测试）在后续测试运行中失败。

在我们的例子中，测试在“ temp”目录中保留了一个文件，该文件具有首次运行该测试的用户的权限。当其他用户尝试在同一台机器上进行测试时：繁荣。在詹姆士卡尔（James Carr）网站上的评论中，约阿金（Joakim Ohlrogge）将其称为“草率工人”，这是“慷慨剩菜”灵感的一部分。我更喜欢我的名字（侮辱更少，更熟悉）。

杜鹃 -弗兰克·卡弗（Cuckoo -Frank Carver）
单元测试，它与其他多个测试案例一起位于一个测试案例中，并且与该测试案例中的其他测试具有相同的（可能很长）设置过程，但随后会丢弃设置中的部分或全部工件并创造自己的。
的高级症状：不当共享治具

秘密捕手 -弗兰克·卡弗（Frank Carver）
一种测试，由于没有断言，乍看之下似乎没有进行任何测试。但是“魔鬼在细节中” ..测试实际上依赖于抛出异常，并且期望测试框架捕获异常并将其报告给用户为失败。

[Test]
public void ShouldNotThrow()
{
   DoSomethingThatShouldNotThrowAnException();
}

环境破坏者

使用和设置环境变量/端口，针对各种“需求”的“单元”测试开始溢出到其环境中。同时运行其中两个测试将导致“端口不可用”异常等。

这些测试将是间歇性的，并使开发人员说诸如“再次运行它”之类的事情。

我见过的一种解决方案是随机选择要使用的端口号。这样可以减少发生冲突的可能性，但是显然不能解决问题。因此，如果可以的话，请始终对代码进行模拟，以使其实际上不会分配不可共享的资源。

图灵测试

一个测试用例是由一些昂贵的工具自动生成的，该工具使用一些过于精明的数据流分析方法，从被测类中收集了许多很多断言。使开发人员误以为他们的代码已经过良好的测试，这使他们免于设计和维护高质量测试的责任。如果机器可以为您编写测试，为什么不能伸出手指来编写应用程序呢！

你好笨 -世界上最聪明的计算机，到新的学徒（从旧的Amiga漫画）。

四十英尺杆测试

由于这些测试过于接近他们要测试的类，因此它们之间的距离很远，被无数的抽象层和他们正在检查的逻辑中的数千行代码分隔开。因此，它们极易碎，并且容易受到往返于感兴趣类的史诗般旅程中发生的各种副作用的影响。

多佩尔甘格

为了测试某些内容，您必须将被测代码的一部分复制到具有相同名称和程序包的新类中，并且必须使用classpath magic或自定义类加载器来确保首先可见（因此，请选择副本）向上）。

此模式表示您无法通过测试控制的隐藏依赖项数量不正常。

我看着他的脸...我的脸！它就像一面镜子，但使我的血液冻结了。

母鸡 -弗兰克·卡弗（Frank Carver）
这是一种通用设置，其功能远远超出实际测试用例的需求。例如，当测试仅断言某些事物的存在或不存在时，创建各种复杂的数据结构，这些结构中填充了看似重要的唯一值。
的高级症状：夹具共享不当

我不知道它的作用...我还是在添加它，以防万一。-匿名开发人员

全部测试

我不敢相信到目前为止还没有提到这一点，但是测试不应该违反“ 单一责任原则”。

我已经碰到了很多次，从定义上说，违反该规则的测试是一场噩梦。

打线者

乍看之下，测试涵盖了所有内容，并且代码覆盖率工具可以100％确认这一点，但实际上，测试仅会击中代码而没有任何输出分析。

覆盖率-可达代码