对测试驱动开发的一些理解

测试驱动开发解决什么问题？

• 系统测试和集成测试不容易覆盖一些代码细节，难以做到很高的代码覆盖率；测试驱动开发编写的测试一般是单元测试，而且由开发者编写，针对单个模块容易做到各个情景的测试覆盖。

• 系统测试和集成测试太慢；单元测试快。

• 测试人员添加测试对功能或者BUG进行回归的周期太长，反馈不及时，不利于开发积极性；测试驱动开发测试先行，每次聚焦一个细粒度问题，测试通过表示问题解决，反馈及时开发容易有成就感。

• 测试人员添加测试对功能或者BUG进行回归的周期太长，如果开发团队较大或者对某个模块的修改比较频繁，可能会因为回归不及时造成功能被破坏或者修复的BUG重现；测试驱动开发测试先行，不会有回归不及时的情况。

• 使用系统测试或集成测试对功能或BUG进行回归，很难聚焦和定位问题；测试驱动开发每个测试只覆盖一个情景，一旦测试失败，几乎不需要调试就知道问题出在什么地方。

• 调试难，有时调试一个问题需要几天，调试的效率和方便性比较依赖于开发环境和开发工具；测试驱动开发可以减少很多调试。

测试驱动开发可能有什么问题？

说“可能”是因为我的理解不深刻，有些情景纯属想象而没有相应的实践经验和总结

• 有些情况下对象之间在业务上就有很多关联和耦合，虽然可以增加接口进行解耦，但是构建测试上下文的过程会变得比较复杂。

• 测试也是代码，在需求变化比较频繁，或者是开发的试验阶段，或者程序结构变化频繁的时候，测试本身可能不容易维护。

测试驱动开发有什么优点？

除了上面测试驱动开发解决的问题之外的，额外的优点

• 测试即文档，单元测试是不会说谎的文档。

• 测试驱动开发是对开发的限制，如果测试写得好，程序的设计就不会太差，模块的耦合性就不会太强，BUG就不会太多。

• 修改代码的时候会比较有保障。

• 编写测试时的过程可以帮助自己理解和细化需求，分解问题，然后逐个覆盖逐个解决，步步为营；

• 用测试驱动替代调试的好处，完成功能或者修复BUG的同时也完成回归；

• 结硬寨（测试），打呆仗（开发）；扎实，少犯错，少走弯路。

测试驱动开发实践方法

测试驱动开发三纪律

• 没有测试之前不要写任何产品代码；

• 只编写恰好能够体现一个失败情况的单元测试代码；

• 只编写恰好能够使一个失败的单元测试通过的产品代码。

测试驱动开发微循环

每次只关注解决一个问题

测试—>实现—>重构—>测试……