九、需要人工干预的测试
自动对系统进行检测是测试的一大优点。它可以确保不因为个人的疏忽而遗漏对某些方面的检查，同时不增加程序员的工作量。某些情况下，会有相当的诱惑使你想要简单的输出结果来通过人工来比较，比如文件的内容或界面布局等。人一眼可以看到的问题，可能需要费相当的功夫才能写成测试的判断。但是要记得，测试的成本并非只是写它的时候付出的努力，同时还包括每次执行时你需要作的工作。所以，让它尽可能的傻瓜化，你就会越多的执行它，它对你的帮助就会更大。
对这种较为复杂的问题写测试的另一个好处是可以仔细的让自己想想到底想要保证什么准则不被违反，需要测试的是什么？
我碰到的另一种需要人工干预的情况是测试的过程中包括了一个需要用户输入的模态对话框，整个流程会停止，直到接收用户的输入为止。这样的测试如果用在DailyBuilding中简直就是灾难。引起它的原因是测试的逻辑与界面操作没有分离。
八、复杂的测试配置环境
有没有试过为了测一个方法，必须得先生成2个全局的单体对象，再设置10个局部变量。在每个TestCase的Setup和TearDown里都是大堆的生成测试环境的代码。造成这种情况的原因是在被测对象内部的代码之间依赖于全局的对象和变量。应该通过接口将这种依赖显式规范出来。
七、牵一发而动全身的测试代码
改了一个类输入输出的约定后，你发现有20多个测试用例都被打破了。更糟的是，你发现每次这样的改动都会面临同样的问题。
耦合的测试反映的是耦合的程序结构，需要采取各项解耦的方法来使变化的范围不致于蔓延。另一个造成这种问题的原因是测试的代码在测试实现而非意图。这样当程序的内部行为变化的时候，测试也不得不随之改变。这种情况在给已有的代码添加测试时特别容易发生。
六、针对代码而非功能的测试
有没有见过对一个相加方法写出上百句的测试？包括了各种可能的取值组合和各类边界情况。或者看到一个复杂的测试过程，像爆米花一样上下翻飞各种数据，但是你却还得通过过程含混不清名字来猜测它的意图究竟如何。
测试驱动开发并非测试，不必责备求全覆盖所有的测试情况。好的测试应该清楚的表达你希望程序达到的意图，并保证程序真的符合这些意图。
五、巨大的TestCase
TestCase对应程序中的一个模块，一般来说是一个类。过于庞杂的TestCase说明对应的类的职责过多，应该参考《重构》中抽取类的方法把它进行分解。
另一种情况是这个TestCase对应的类提供整体的服务，而在内部调用其他对象的操作。如果仅仅在最外层进行测试，往往有很多内容要测，并且需要考虑每个部分的不同情况的组合。对这种情况，需要用接口显式的定义这个类和其他局部的委托关系，再通过虚拟对象隔离两者进行测试。
四、红灯常明
失败的测试表示系统中有某项约定已经被打破了，因而为了保证系统的正常运行，必须尽快修正这一问题。坐视某个测试没有通过往往是由于这个测试已经不适合现在的程序结构了（事实上，这是由于另一个错误，先写代码再写测试引起的）。对这个测试进行修改，或者干脆删除它。丧失了对红灯的警觉就等于丧失了测试驱动开发的大部分好处。
三、大跨度的测试
提供了系统最外层的输入，然后就变魔术般的输出最终结果。作为验收测试是适当的，而且往往写下的第一个测试就是这样高层次测试。但是，如果仅仅有这种测试是不够的。需要有更多的说明产生这一结果的机制的测试代码。
判断测试跨度的一个标准就是，每个测试应该在几小时内得以通过（我的极限是一天，不同的人可能适应更小的粒度）。如果写下一个测试后需要奋斗一周的时间才看到结果，那么TDD对你不会有太大的帮助。应该尽快的通过虚拟对象通过高层测试，并将注意力集中到更低层次对象需要满足的测试上。
二、衣不蔽体的测试
有些上万行代码的工程中仅仅有2、3个TestCase，往往是对某些“核心”模块或复杂算法所作的。或者仅仅是某个人试试IDE的新功能的结果。这样的使用方式根本和测试驱动开发不沾边。测试用例并不是一条安全索，而是类似脚手架那样，是设计和实现的手段和一个组成部分。
我很幸运，基本上前面提到的错误都曾犯过，而且可能还会再以后还会再犯各种不同的错。然而我感觉这些错误都不如那最大的错误：
一、不写测试
有很多理由可以用来拒绝TDD：进度太紧，哪有时间写测试；这种方式太古怪，无法接受；你所从事的领域过于特殊，并不适合测试驱动开发的方式；有些代码根本写不出测试……
接受“人是会犯错的”这个事实（不论是在写程序，还是在应用新的开发过程的时候），并面对这些错误、研究它们，定义它们、检查并且清晰的反馈结果。最终，也许你会发现当初的恐惧已经随着一步步的深入烟消云散，而你的脚步也早已扩展到了原来未曾涉及的领域。
