测试驱动开发对于软件开发重构的意义

相对于已经成熟的软件公司，很过国内的软件公司，乃至于欧美的一些软件公司，都还存在着很多手工业式的软件开发和管理方式，通过需求快速建立原型，原型验证之后直接基于原有代码实现功能点，将功能点交给测试，然后提交bug，修复bug这一流程。尤其是在项目紧任务重的情形下，这种现象凸显的尤其严重。而当产品和项目继续进行，原有需要进行变动的时候，就会出现牵一发动全身的情况，好多原来测过的功能点出现bug。耗费大量的研发和测试资源。

而在软件开发过程中，引入测试驱动开发的概念和对代码建立响应的单元测试则能够很好的避免一些问题。

首先，在开发之前，测试用例能够对设计进行验证。在测试驱动开发的概念中，编写代码之前，首先要编写测试代码，从开发人员的角度讲，似乎并不是很习惯这种编程方式。在没有任何代码的情况下去编写单元测试的用例，相对于编写代码解决当前的问题而言，对于绝大部分程序员来说都会去选择后者。其实对于程序员上手编程的时候，很多情况下自己对于程序的结构并没有完全清楚，需要使用代码去验证和延展自己的思路，在程序的编写和调试的过程中，去完善和整理自己的实现方式。这样实现出来的代码，难免的会带有很多的代码之间的耦合和对于环境的依赖。而如果基于测试驱动开发入手，那么程序员首先要关注的就不再是实现的过程，比较使用代码一边实现一边验证的过程，程序员需要首先将自己的实现和设计理顺，转化为可以进行单元测试的代码。那么这种转换的代码就会有两个优势，第一个优势是，代码是低耦合的，由于要进行单元测试，那么首先，代码必须要分成一个个的部分，代码之间的界限是清晰，可装配的。这样才可以方便的进行单元测试，这也就避免了很多把几个功能点糅合在了一起，当要进行重用的时候，不能将代码良好的抽出的情况。第二点，就是代码对于环境的依赖是有限的，比如在直接实现代码的过程中，可以直接使用httpcontext， httpcache等系统提供的功能，而在单元测试的环境的中，这些值就会为空，而不能进行测试，那么对于良好的程序设计而言，隔离这些对于环境的影响也是非常重要的一个部分。

这也就是说，使用测试驱动开发，在开始编程的前期，软件和程序的设计和边界是清晰的，对于任何方法的实现，输入，输出，参数个数，参数类型，都是经过了相应的用例考验的，从而完成对程序的设计一次验证。而令一方面，也降低了程序逻辑本身对于开发环境的依赖，大大增加了程序的可移植性。

其次，对于没有良好的单元测试进行匹配项目，当项目依赖用户需求进行改动的时候，程序员经常会产生对于自己改动没有信心的情况，大部分程序员不喜欢进行测试工作，尤其是手动测试，对于将项目运行起来，挨个的输入参数，验证。那么在主体功能跑通之后，这部分更改的代码就提交给了测试或者相应的合作团队，而在这个过程中，合作团队和测试团队需要对每一个细节进行验证，如果出现问题的话，需要再去沟通，更改，重新生成项目，而其他部分产生的bug，很可能是因为改变了这部分的代码，而对于一些代码，可能在系统中进行多次的引用，而这样的变动，没有相应的测试用例进行把关，无疑会产生巨大的团队成本。

再次，程序员对于程序都有重构的习惯，而重构意味着代码或多或少的变动，如果这些变动只依赖于程序员自己的思维和经验来保证的话，毫无疑问可能会给项目带来巨大的问题，而当有相应的测试用例进行“保驾护航”的话，毫无疑问，程序员的信心会有很大的增强。

虽然测试驱动开发，本身需要付出一部分成本来创建单元测试，如果严格的要求在任何一个功能点开发都去相应的功能，逻辑，和边界值的单元测试，那么代价却是有些高昂。但是，这种方式的确能够很好的改变手工业式软件生产的生产方式，杜绝大部分问题，能够很好的将软件的设计进行验证，保证接口的合理性，在项目功能变更的时候保证质量，在进行重构的时候保持代码的更改局限于实现本身，并保证产品的质量。在有条件和成本的情况下，采用这种方式虽然在初期增加了开发成本，但是在维护和项目变更的过程中，却会节省大量的成本。