• 添加一个规模较小的测试
• 运行测试并找出哪些测试失败
• 修改程序代码
• 再次运行测试直到测试通过
• 进行重构来消除重复部分

• 伪实现（Fake It）：返回一个常量，逐渐使用变量取代它直到代码实现。
• 显明实现（Obvious Implementation）：键入真正的代码实现。
• 三角测量（Triangulation）：当你有两个或者更多的例子时，才能进行抽象。

• 测试驱动开发的要点不在于采取了哪些措施，而在于能够取得这些微小进步本身。
• 如果你能够做到很小的改进，也一定可以完成你所需要规模的改进。如果只是做后者，那么你将永远不知道更小的改进是否合适。
• 将一种认识（例如，对副效应的厌恶）转换为一个测试，是测试驱动开发中常见的做法。
• 好的设计应该三在完成的时候，使其能够运行，并且正确。
• 当你没有充分地测试时，就会受限于在未经测试的前提下就进行的重构。你可能会犯重构的错误然而测试却仍然可以运行。
• 请编写你希望本来就有的测试。如果不这样做，在重构的时候最终会破坏某些地方，随后你对重构便会有不爽的感觉，并且导致不愿再做过多的重构。这使得你的设计变得不如先前的好，最终导致你被解雇。宠物狗也将离你而去，你也不再关注自己的健康，牙齿也会随之变糟……所以为了保持你的牙齿健康，在重构前请别忘记测试。
• 当且仅当一个测试存在并且正确运行时，另一个测试才可以简化。
• 除非存在未通过的测试，否则，就不能键入任何程序代码。
• 测试是程序员的试金石，能够将恐惧化为浮云。
• 测试之间一定不要互相干扰。隔离测试的现实意义在于测试是顺序无关的。隔离测试鼓励你使用高内聚、低耦合的对象组成解决方案。
• 在测试驱动开发的理想形式中，只能有一处导致脱离绿色指示条的修改。
• 某个测试可能无法工作的话，那么将测试调试通过远比发布代码要重要得多。
• 未通过的测试即是你没有充分理解所编程序的有力佐证。

如何测试软件呢？ 请编写一个自动化测试程序。

测试间的运行应该如何互相影响呢？ 根本不需要！

应该测试什么呢？ 在开始之前，请编写一个你所知必须完成的测试列表。应对编程压力的首要方法就是，在我们知道如何去做之前，永远不要向前迈出那一步。

应该什么时候编写测试呢？ 在你编写要被测试的代码前。

什么时候写断言呢？ 请最先编写。

在测试优先编程模式下的测试中，使用哪些数据呢？ 请使用那些使测试易读性强且易于理解的数据。测试数据中的一项技巧是永远不要试图使用同一个常量表示一个以上的事物。

如何表达数据的含义呢？ 包括测试本身的期望结果和实际结果，并尽量让它们的关系明朗起来。

从测试列表中选择哪个测试呢？ 请选那个具有指导意义，并且你有信心能够实现的测试。

应该从哪个测试开始呢？ 请从测试一组不做任何事情的操作开始。

如何扩展自动化测试的用处呢？ 请就测试而言要求说明并给予解释。

什么时候为外来的软件编写测试呢？ 在你初次使用它的某个新功能的时候。

如何让技术讨论不偏离主题呢？ 当一个离题的想法出现的时候，把它添加到列表中，然后再回到正在讨论的话题。

当发现一个软件缺陷的时候，首先做什么？ 请编写尽可能简单而相应无法通过的测试，一旦测试运行通过，那么缺陷也就被修复了。 回归测试是这样的一种测试，是你在编码之初就应该编写的测试，并且完全预知运行结果。

当感觉疲倦并且不知所措的时候，怎么办？ 休息一下吧！ 如果你知道做什么，那就使用显明实现。如果你不知道该做什么，那么就使用伪实现。如果正确的设计还不明朗的话，那就使用三角测量法。如果你还是不知道该怎么办，那你就去洗澡吧！

你感到迷惘的时候会做什么？ 扔掉已有的代码并重新开始把！

如何使一个编写规模非常大的测试运行呢？ 编写一个代表该测试某个部分的较小规模的测试。让小规模的测试运行，然后再引入更大规模的测试。

如何测试一个对象？ 这个对象依赖于价值昂贵或构成比较复杂的资源，请创建一个与该资源相对应的伪版本测试。

如何来测试一个对象与另外一个是否正常交互呢？ 请让测试对象与测试用例进行交互，而不是与我们所期望的对象进行交互。

怎么测试不太可能被触发的错误码呢？ 请通过一个只抛出异常而不做任何实质工作的对象，使用任何方式来触发错误码。

当你独自一个人编写程序的时候，如何处理起身离开时目前正在编写的测试呢？ 请让最后一个测试保持不完整的状态。

你在一个团队中编程的时候，怎么结束编程工作呢？ 请让全部测试都运行起来。

一旦你遇到了无法通过的测试，首先要做什么？ 请返回一个常量！你一旦使测试运行起来了，请逐渐将常量转变成变量表示的表达式。

如何最为稳妥地在测试中进行抽象呢？ 当你有两个或者更多的例子时，才能进行抽象。

如何来实现简单的操作呢？ 直接实现吧！

如何实现一个用于对象集的操作呢？ 请现在去掉集合的情况下实现它，然后，再把集合加进去。