TDD学习总结

测试驱动的含义

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

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

• 原有开发流程是理解需求——编码——编写测试代码——自行验证——提交测试

• 测试驱动流程单元测试——编写代码——单元测试——编写代码…直到完成功能——最终进行代码重构。其实重构伴随整个编码过程。

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

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

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

  重构

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

  回归测试

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

需求到测试

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

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

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

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

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

• 单元测试应该具有 原子性和独立性
• 单元测试先行的模式注重的是我可以有什么东西（即我应该写什么表达意图的方法，同时隔离了方法实现的细节），注意力永远在新的东西上面，因为基于原子性和独立性，你无需关注已有的东西（他们是相互隔离的）

这一步需要对于事物的拆解能力，拆的越细TDD的作用越明显。其实这种对待需求的思想貌似就是你正在遵循的，只是TDD以一种流程化的形式进行了描述。

• 测试编写的形式

  广度优先：注重高层的功能实现而相关的细节首先以伪实现的形式满足

  深度优先：注重细节实现，逐步扩展到高层功能

  平时开发接口的事后，可以先采用广度优先的策略来设计整体的功能架构，后面则一深度优先的策略来完成细节。每个阶段都有你觉得最合适的策略，所以两种策略可以随时切换