【基本步骤及流程】
1. 根据问题进行初始的需求分析，提取出初始而不完备的【to-do】列表；
2. 选择【 to-do】列表中的某个【to-do】， 编写相应的测试；
3. 运行测试，发现无法通过；
4. 作出最简单的的改进，并运行测试使之通过；
5. 一小步一小步地重构代码、运行测试，并使之通过；
6. 跳转至【2】。
【关键要素】
1.【to-do】列表： 需要完成的任务、当前要做的事情、标识完工。
2. the effective test for the to-do chosen: 为 to-do 列表的 to-do 编写有效的测试；
3. the simplest code for passing test: 使用最简单的方法使测试通过；
4. code refactoring: 通过代码重构，使其符合良好的软件设计理念，并使测试通过。
【核心理念】
1. First Test Then Code: 【先测试后编码】的开发习惯
始终保持【先写测试后编码实现】的开发习惯，这是测试驱动开发的最重要的宗旨。
2. Teensy-weensy Steps: 【一小步一小步、化整为零】的前进策略
① 始终通过【一小步一小步、化整为零】 的策略来保证均匀地向前推进，不贪求局部快速，但求全局的前进步调。
② 通过 teensy-weensy steps 可以将复杂的开发、重构过程化解为简单的、容易实现的步骤。
【核心理念解析】
1. 测试驱动的开发，其主要意图就是使代码总是处于测试的监督之下。
当进行代码重构和维护时，能够清晰地看到新的代码 对原有系统的影响，能够充满自信地进行重构和维护。
2. 关于【一小步一小步前进，化整为零】的策略：
① 并不一定总是遵循【一小步一小步】的方式，而是使你【总是能够】一小步一小步的前进，最终达到终点；
② 在测试驱动开发的理念中，新添一个小测试，无法通过测试、通过测试，都是向目标前进，都是进步。
③ 如果急切地推进，违背【一小步一小步】的策略，当出现错误而无法通过测试时，就会僵在那里，而无法前进。
First make it works, Then make it right.
【基本问题与解答】
1. 如何开始【TDD】 ？
利用传统的问题分析技能，进行简单而初始的需求分析， 并形成初始的【 to-do】 列表；
该【to-do】列表通常是对问题直观的理解得到的，是不完备的，在【测试-编码-重构】过程中会逐步加以完善。
2. 完成初始【to-do】列表后的第一个步骤？
以第一个测试开始，而不是编写第一个类开始。非常重要，谨记，要克服【先编码后测试】的惯性。
3. 选取【to-do】列表中的哪个【to-do】？
通常选择最容易实现的那个【to-do】，有时也凭直觉，但始终遵循【从最简单的地方入手】的原则。
4. 如何为选定的【to-do】编写有效的测试？
① 一开始总是编写最直观最简单的测试；
② 在代码重构阶段，可能会改变对象接口，从而需要对测试代码进行重构， 使测试仍然执行原有的测试功能，同时更加有效。
5. 如何作出简单的改进尽快使测试通过？
① 通过构造空实现及存根方法，使测试尽快编译通过，但功能测试将失败；
② 使用蛮力的硬编码，使用能够想到的最简单的方法，不择手段。
6. 如何重构代码，使测试通过？
这是测试驱动开发的难点；要掌握良好的重构技术和软件设计素养才能更好的做好这一步。
一个比较容易的方法是，一小步一小步地重构，重构之后立即运行测试。
7. 如何标识完工？
每当通过代码重构使选定【to-do】的相应测试通过时，就从 to-do 列表上划掉它； 直至【to-do】列表上的所有【to-do】都被划掉为止。
8. 如何标识当前正在做的事情？
在选定【to-do】上作某种标记，比如下划线，圈圈等。
【高级话题及思考】
9. 如何确保【to-do】列表能够完全地覆盖问题所要求的功能及约束 ？
① 当在开发过程中发现新的需求时，就将它添加到 to-do 列表中；【TDD】的需求分析是渐增式的。
② 在所有【to-do】完成之后，还要进行综合测试审核，以保证确实完全地覆盖了问题所要求的功能及约束。
【TDD】并不是要消除传统的测试阶段，而是使最后的单元测试、集成测试、验收测试等更容易进行， 降低测试和维护成本。
10. 如何确保【TDD】所获得的软件总体设计是良好的、可扩展性强的？
【TDD】并非不注重软件设计；它在代码重构过程中引入了软件设计， 从而使软件通过渐增式的【局部最优设计】最终达到【全局最优设计】；这看上去类似【贪心策略】。
11. 在【TDD】中，如何处理需求与测试之间的关系 ？
【TDD】将需求转化为【to-do】列表，然后进一步转化为测试集合。
它将项目任务【以需求为中心】转化为【以测试为中心】，因此，必须保证测试集合的有效性，
否则，即使通过了所有的测试，也毫无意义；测试集合必须能够完全表征所有的需求。
12. 在【TDD】中，如何处理测试与设计之间的关系 ？
【TDD】并没有指明设计与测试之间的关系和先后顺序；
测试代码也可能需要重构，以改善测试效果；测试代码的重构将带来产品代码的重构和变化。
测试驱动的开发需要运用大量的重构技术； 而在重构过程中引入良好的软件设计，实际上对软件设计的要求也是比较高的。
13. 在【TDD】中，如何界定【一小步】？
【TDD】并不意味着非要机械地按上述步骤完成；这些步骤仅为初学者设计；
迭代步骤和节奏，可以根据自己的实际设计和编程水平而有所变化。
14. 【TDD】适用于哪些场合 ？如何将它运用于大型项目 ？
① 对于小型项目而言，【TDD】完全能够胜任；
② 对于大型项目而言， 开发人员个体可以使用【TDD】来完成自己的模块任务；
③ 【TDD】中测试、编码、设计工作如何分离和分工呢 ？
15. 【TDD】如何保证测试是有效的 ？
测试管理是【TDD】中一个关键点；如果测试不是有效的，就不能保证代码实现了所要求的功能。
必须有效地将需求转化为测试，使测试能够完全地表征需求。
【例外】
① 有时，需要采取【以退为进】的策略，适当地降低设计的质量，回退到重复代码的状态，
以另一种重构来寻找突破口。
② 由于有了详尽的测试以及重构好的干净代码，通常只需要做实验来验证新想法是否可行，
不需要绞尽脑汁对系统行为进行推理，害怕重构会破坏原有系统。
③ 在某些关键点上需要放慢速度，对设计思路进行仔细思量，来写出有效的测试，使接下来的系统构建具有良好的可扩展性；
即在编写测试之前进行设计考量；此时，可能需要丰富的实际设计经验来引导作出更好的决策。
④ 极少量的情况下，会在亮红灯的情况下仍然贸然前进，编写新的测试；
⑤ 编写用于调试的方法【比如 toString】及帮助类时，可以不写测试，而直接参与到重构过程中。