反模式:必须至少有两个关键元素来正式区分实际的反模式与简单的坏习惯、坏实践或坏想法:

一些重复的行为模式、过程或结构,最初看起来是有益的,但最终产生的坏结果多于有益的结果 一个重构的解决方案,清楚地记录,在实际实践中证明,并可重复。

为您在“野外”中见过太多次的TDD反模式投票。 James Carr的博客文章和testdrivendevelopment yahoogroup的相关讨论

如果你找到了一个“未命名的”…也要贴出来。请每个反模式一篇文章,让投票有意义。

我的既得利益是找到前n个子集,这样我就可以在不久的将来在午餐会上讨论它们。


当前回答

当我看到一些闪烁的gui时,我才会相信 一种不健康的执着/痴迷于通过图形用户界面测试应用程序,就像一个真正的用户一样

通过GUI测试业务规则 是一种可怕的结合形式。如果 您编写了数千个测试 然后改变你的GUI, 成千上万的测试中断。 相反,只通过GUI测试GUI内容,并将 图形用户界面以虚拟系统代替 真正的系统,当你做这些测试的时候。 通过API测试业务规则 不涉及GUI。——鲍勃·马丁

“你必须明白眼见为实,但也要知道眼见为实。——丹尼斯·韦特利

其他回答

本地英雄

一个测试用例,它依赖于编写它的开发环境中特定的东西来运行。结果是测试通过了开发箱,但是当有人试图在其他地方运行它时失败了。

隐藏的依赖性

与本地英雄密切相关的单元测试,需要在测试运行之前填充一些现有数据。如果这些数据没有被填充,测试就会失败,并且几乎没有给开发人员留下它想要什么或为什么的提示……迫使他们挖掘大量的代码来找出它所使用的数据应该来自哪里。


令人遗憾的是,我们已经多次看到古老的.dll依赖于模糊而多样的.ini文件,这些文件在任何给定的生产系统上都是不同步的,更不用说在没有与负责这些dll的三个开发人员广泛协商的情况下在您的机器上存在。叹息。

等着瞧

一种运行一些设置代码的测试,然后需要“等待”一段特定的时间,才能“看到”被测代码是否按预期运行。使用Thread.sleep()或等效的testMethod肯定是一个“等待和观察”测试。

通常,如果测试正在测试生成系统外部事件(如电子邮件、http请求或将文件写入磁盘)的代码,您可能会看到这种情况。

这样的测试也可能是一个本地英雄,因为当它在较慢的机器或过载的CI服务器上运行时,它将失败。

不要将“等待和观察”反模式与“睡眠者”混淆。

巨大的

一个单元测试,尽管它是有效地测试被测对象,但它可以跨越数千行,并包含许多许多测试用例。这可以作为一个指示器,表明测试中的系统是一个上帝对象(James Carr的帖子)。

对于这种情况,一个明确的迹象是测试跨越了不止几行代码。通常,测试是如此复杂,以至于它开始包含自己的错误或不可靠的行为。

分身

为了测试某些东西,您必须将测试中的部分代码复制到具有相同名称和包的新类中,并且必须使用类路径魔法或自定义类加载器来确保它首先是可见的(这样您的副本就会被拾取)。

此模式表明您无法从测试中控制隐藏依赖项的不健康数量。

我看着他的脸……我的脸!它就像一面镜子,但让我的血液凝固。

以铁链锁住一群做苦工的囚犯

必须以特定顺序运行的几个测试,即一个测试改变了系统的全局状态(全局变量,数据库中的数据),而下一个测试依赖于它。

您经常在数据库测试中看到这种情况。测试不会在teardown()中执行回滚,而是将更改提交给数据库。另一个常见的原因是对全局状态的更改没有包装在try/finally块中,如果测试失败,这些块将被清理。