TDD：正确的项目开发思路

  从以下仅为个人观点，如有疑问和异议，请在评论下留言。

  从事Java开发已经有两年多，会开始考虑如何保障开发以及维护的稳定性，起因有二，一是公司项目总会有修不完的bug，每次的修复，总会引发新的问题出现，导致维护工作反反复复，新工作无法正常的开展；二是自己有创建网站的计划，希望能够避免类似公司项目这样的问题，导致效率低下。实际上，项目的开发，最本质的要求就是：

• 提高开发效率

• 减少维护成本

  为了实现这两个要求，看了很多相关的资料，总结出来以下三点：

• 敏捷开发

• 测试驱动开发

• 重构

  敏捷开发属于方法论，需要经验丰富的从业者驱动；重构属于技术活，要靠技术功底深厚的大牛；这两点不在今天的讨论范围之内，因为都需要经验的沉淀，但是测试驱动开发不同，他属于意识流，无论是刚入门的菜鸟，还是工作十年的老鸟，只有具备正确的思考方式，才能够完成项目的开发。

  测试驱动开发，又名TDD，顾名思义，以测试用例驱动项目开发，与传统的发开模式不同。

• 传统的开发模式：

  1. 功能点需求分析

  2. 根据功能点编码

  3. 反复测试

  4. 修正BUG

  5. 回归

  6. 功能上线

• 测试驱动开发模式：

  1. 功能点需求分析

  2. 根据功能点编写测试用例

  3. 根据测试用例进行编码

  4. 反复测试

  5. 修正BUG

  6. 回归

  7. 功能上线

  传统模式和测试驱动开发模式的区别仅在于第二，第三点，这小小的差别，却对结果有着翻天覆地的影响，可谓差之毫厘，失之千里。测试用例的存在为什么会导致如此大的差距？根据不同的开发阶段，可以对测试驱动开发模式进行分析：

• 设计阶段

  • 基于需求编写的测试用例，可以快速提供产品原型，防止后期需求与描述不符导致返工

  • 基于测试用例的类设计和接口设计，能更好地体现设计意图

• 开发阶段

  • 通过多维度编写的测试用例，可以细致地定位需求的功能点，避免直接编码导致的考虑不周

  • 根据测试用例的划分，逐一击破各个小的功能点，最后集成总功能，属于良性的开发循环，避免一次性将总功能实现所带来的巨大压力

• 代码重构阶段

  • 测试用例可以保证重构代码不会影响到非重构部分，为开发者提供勇气和信心，否则，会因为代码的耦合性而难以重构

• 添加新功能阶段

  • 添加新的测试用例，但新添加的功能不应该影响旧的测试用例，以保证系统的稳定性

说白了，TDD具备以下几点优势：

• 对需求负责（需求如何定义，测试用例就如何定义）

• 多个测试用例可精确描述所有的功能点

• 根据功能点，面向对象设计（对象设计，属性设计，接口设计）【设计的时候，会考虑到开发与到的问题】

• 编码的目的在于跑通一个个测试用例

• 测试用例相当于指南针，可以确保重构时和重构后，功能依旧能正确运行

• 新功能开发 ，继续添加新的测试用例，以保证新功能能在新的测试用例正常运行的同时，确保旧功能也能运行

• 测试代码要不断地更新，从最简单的测试代码到后来相对稳定的代码

• 测试代码是最好的接口文档，运行测试实例，可以从代码层面理解功能