TDD的一些思考

最近考虑在开发中引入TDD的概念，用于提高在进度压迫下的开发效率，搜索了一些资料，对于TDD的定义是这样的：

 

测试驱动开发
测试驱动开发（Test Driven Development,英文缩写TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。

 

以上的定义一定程度阐述了TDD，只是如果将“测试代码”换成“测试用例”就会更加精确些，下面这个定义大家可以细细体会一下：

Test-driven design (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.  

TDD是一种演化后的开发方式，它结合了TFD，即在完成满足测试与重构要求的代码前，先编写测试用例。

 

这就要求测试人员要在项目的一开始（非开发开始）就要加入进来，测试人员除了提前写测试用例, 无论是自动化的还是非自动化的, 而需要测试人员参加的一项重要活动, 就是参与特性验收条件的制定. 之前经常发生开发人员按照自己的理解去编码, 测试人员按照自己的理解去测试, 直到开发完成, 测试过程中才发现理解的不一致, 开始产生争执并阻塞等待产品经理或项目经理的仲裁. 解决办法就是就在开始开发新特性前的一刹那, 由PM, 测试人员, 开发人员进行一次讨论, 就验收条件达成一致并形成记录, 然后测试人员和开发人员分头去写测试和实现。这里就体现了敏捷的特性----减少后期由于理解不一致的带来的成本消耗。

 

测试人员早期的加入还有一个好处，就是帮助开发人员设计制定“规则”。一份需求文档主要的工作是描述这个产品应该做什么，而测试人员编写的测试用例除了要检验“该做的有没有做”以外，另一个重要工作就是“不该做的是不是没做”。这就类似于是需求文档，甚至是设计文档的一种补充及检验。这样TDD就可以使开发人员在开发过程中就开始减少了引入的bug数目。这又是敏捷的另一个特性----减少了bug引入数，进一步减少了测试-修改的迭代次数，节省了时间与人力。

 

If it's worth building, it's worth testing.

If it's not worth testing, why are you wasting your time working on it?