【基本步骤及流程】

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】及帮助类时，可以不写测试，而直接参与到重构过程中。