反模式 ：要正式区分实际的反模式与简单的坏习惯，不良实践或错误想法，必须至少有两个关键因素：
投票选出您“在野外”中见过太多次的TDD反模式。
James Carr的博客文章和testdrivendevelopment Yahoo群组上的相关讨论
如果您发现了一个“未命名”的，请也分享出来。每一个反模式请发表一篇帖子以确保投票有意义。
我的目的是找到前N种反模式，以便在不久的将来的午餐会议上讨论它们。
二等公民 - 测试代码没有像生产代码一样进行良好的重构，存在大量重复代码，使得维护测试变得困难。
免费搭车/顺风车 -- James Carr, Tim Ottinger
与其编写一个新的测试用例方法来测试另一个/不同的功能特性，一种新的断言（以及其对应的操作，即 AAA 中的 Act 步骤）会在现有的测试用例中顺带而来。
checkInvariants()验证函数中，并在每个测试中使用它。代码更改并添加了另一个不变量。当然，您也会将其放入该函数中。但它是一个免费乘客。 - Raedwald本地英雄（The Local Hero）
一种测试用例，依赖于特定于编写它的开发环境的某些内容才能运行。这导致测试在开发人员的机器上通过，但是当其他人尝试在别处运行时，则无法通过。
隐藏依赖（The Hidden Dependency）
与本地英雄密切相关，一种单元测试需要在测试运行之前已经存在某些数据。如果数据未被填充，测试将失败，并且很难让开发人员知道测试需要什么或为什么会失败，迫使他们深入查找代码以找出数据来自哪里。
遗憾的是，我们在过去看到太多这种情况，古老的.dll文件依赖于模糊而不同的.ini文件，在任何给定的生产系统上都会不断失效，更不用说在没有与负责那些.dll文件的三名开发人员进行广泛协商的情况下，在您的机器上存留这些文件了。唉。
链式测试
一些必须按特定顺序运行的测试，即一个测试更改系统的全局状态（全局变量，数据库中的数据），而下一个测试则依赖于其结果。
在数据库测试中经常看到这种情况。测试不会在teardown()中执行回滚操作，而是提交对数据库的更改。另一个常见原因是对全局状态的更改没有包装在try/finally块中，在测试失败时无法清理。
嘲弄(Mockery)
有时候，嘲弄能够很好地辅助开发。但是，有些开发者在模拟未被测试的内容时，可能会失去自我。在这种情况下，一个单元测试包含了太多的模拟、存根和/或伪装，以至于被测试的系统根本没有被真正地测试，而是被用来测试从模拟中返回的数据。
来源：詹姆斯·卡尔（James Carr）的文章。
悄无声息的捕手 -- Kelly?
如果抛出了异常，即使实际发生的异常与开发人员预期的异常不同，也会通过测试。
参见：秘密捕手
[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
// some code that throws another exception yet passes the test
}
检查器
一种单元测试，违反封装性以实现100％代码覆盖率，但是它对对象的运行情况了解太多，任何重构的尝试都会破坏现有测试，并要求对单元测试进行任何更改。
'我如何在不将成员变量公开的情况下进行测试...只是为了单元测试？'
过度的设置 -- James Carr
一种需要大量设置才能开始测试的测试。有时需要使用几百行代码来为一个测试准备环境，涉及多个对象，这使得由于所有设置所带来的“噪音”，很难真正确定测试的内容。(来源：James Carr的文章)
分析探针
这是一种必须使用疯狂、非法或其他不健康的方式来执行任务的测试，例如：使用Java的setAccessible(true)读取私有字段或扩展类以访问受保护的字段/方法，或者必须将测试放置在特定包中以访问包全局字段/方法。
如果您看到这种模式，则表示被测试的类使用了过多的数据隐藏。
与检查器的区别在于，被测试的类试图隐藏甚至需要测试的内容。因此，您的目标不是实现100％的测试覆盖率，而是能够进行任何测试。想象一个只有私有字段、没有参数的run()方法和没有getter的类。没有办法在不违反规则的情况下进行测试。
迈克尔·博格沃特评论：这不是真正的测试反模式，而是实用主义来处理被测试代码中的缺陷。当然，更好的方法是修复这些缺陷，但在第三方库的情况下可能无法实现。
亚伦·迪古拉：我有点同意。也许这篇文章确实更适合作为“JUnit HOWTO”维基而不是一个反模式。有什么评论吗？