测试驱动的含义

敏捷开发在快速迭代的过程中，不断向客户交付产品，产品的质量如何保证就是个问题，往往时间周期短任务量大都会导致代码质量的下降。

对于持续交付和维护的项目代码质量更为重要

原有开发流程是理解需求——编码——编写测试代码——自行验证——提交测试
测试驱动流程单元测试——编写代码——单元测试——编写代码…直到完成功能——最终进行代码重构。其实重构伴随整个编码过程。

个人理解：代码的质量依赖于单元测试，而单元测试依赖于需求。将代码的质量保证交由需求去驱动，即通过逐步分析需求产出单元测试

编写满足单元测试的代码，如此往复。最终每一行代码都来自于测试驱动，而每一小部分的测试来自于需求驱动。只要单元测试能够清晰

描述需求那么代码的质量就自然而然得到保证（前提要满足基本编码设计原则，这一部分交由重构完成）

重构

重构即是在代码行为没有改变的条件下对代码结构和设计的一种调整，重构过程中应该遵守“童子军原则“避免“破窗效应”。

回归测试

检验代码的改动是否影响软件现有的功能，即是软件是否回归到不可用或者缺陷状态。

需求到测试

需求描述了可能需要的一组功能，而功能是宽泛。例如一个生成报表的功能，从这个描述可能只能得到需要生成一个报表，但是需求中会有很多隐藏的要求，

例如报表应该不能太大（导出超时）、报表导出成功后需要发邮件通知、报表的列的顺序等等（粗略一看好像这些都是需求应该给出来的，貌似与TDD

没有啥关系。当然了这只是一个简单的例子。）

个人理解：其实TDD中的测试其实就是将需求进行细化，同时将细化后的“需求”进行测试描述，目的是“需求”（单元测试）原子化。这种“需求”可能是报表导出后，文件格式是.XSL，可能你会觉得这也太简单了。其实在以往的编码中，这些步骤验证都自动的发生在我们的脑子里，但存在的问题就是有时候会忽视一些小细节。

如果我们将这些验证以一种语言描述出来，然后不断的契合验证，增加验证，循环往复。即TDD所指导的则是以单元测试来描述这些验证，基于单元测试进行编码…