TDD( 测试驱动开发) Overview

第一篇技术博客，希望有人支持，您的关注是我的动力...

本文主要是基于本人的开发经验，概叙一下TDD，也就是测试驱动开发。我比较喜欢用问题方式来写，语言水平有限 希望读者看得懂且有帮助

TDD这个东西 你一般用了之后会上瘾:) 它可能改变你以后的编程习惯

什么是TDD

故名思意就是用测试的方法驱动开发。简单说就是先写测试代码，再写开发代码，和传统的方式是反的。

为什么要用TDD

用TDD的方法可以使代码干净（代码重构的结果），测试覆盖率高（先写测试的结果），软件做集成测试的时候一般问题会比较少。

而且你敢改人家的代码，看到有fail的test case 证明你有改错人家的东西，看到所有的test case都过了的话，你也很有信心说，我没有改错，或程序不会因为我的改动而挂掉。

什么时候TDD

TDD是在Unit Test,  也就是单元测试时用的方法。

什么地方TDD

我觉得写任何代码都可以用TDD吧

怎么做TDD（关键5步）

1. 加入一个新的测试
2. 运行下新加的测试，看到它失败（因为你还没写功能代码）
3. 对开发代码做很小的修改，目的就是让新加的测试通过 （注意这里的目的）
4. 运行所有的测试（test case），然后看到所有测试都通过了 （看到测试都变成绿色，一般都会小开心一下）
5. 移掉重复的代码，对代码进行重构 （既包括功能代码，也包括测试代码。特别注意红色的字串 一般会有重复，还有一些代码可以抽出来变成公用方法，测试代码中同样的初始化和还原测试环境的代码，可以放到intilize和cleanup中去）

而外还有一些步骤也是可以加入的，比方

• 在写测试代码前，先从需求出发，准备一个Test list (需要测到的功能的列表)。忘掉你该怎么实现，那是后面的事情
• 每测完一个就用横线划掉
• 如果发现有漏掉的test 就加到这个列表中（列表测完你的功能也就完成了）

TDD的好处，和不足的地方

好处

• 测试代码都是从客户需求出发的，不是重实现出发的。测试更关注于对外部的接口。
• 软件的需求都被测试代码描叙得很清楚，可以减少很多不必要的文档（有些时候写文档时间比开发时间多多了, 需要一个专门写文档的，而且用的机会很少。这里我很喜欢敏捷开发中说的：Just enough）
• 每次都是很小的步骤，这样你就很集中注意解决一个问题。葛优说的：步子迈大了容易扯着蛋，步子大想的就多，容易忽视些东西， 容易出错。小而简单就是美
• 可以优化设计。如果有做过测试驱动开发的会发现，为了更好的，更容易的做单元测试。它逼着你面向接口编程和使用一些设计模式，自然设计就灵活了，耦合性也低

缺点

• 有时候开发代码可能只有几行，可是测试代码可能比真正的代码要多很多。而且花时间想怎么测试。
• 可能不适合时间很紧的软件开发，更适合于产品和平台的开发

怎么学习TDD最好

我觉得最好且最快的方式就是 XP中提到的结对编程，一个有TDD经验的坐在"后面"，指导另一个不大熟悉的人，两人一起来完成一个类或模块的功能

几个关键点

• 记得你是做单元测试，不是集成测试，你要测得仅仅是你的类的功能，不要去测别人类的功能，一定要知道测到什么程度就好了，剩下的可能是别人需要测的
• 每次都是一小步，目的只是用最简单的方法让新加的test case过掉而已
• 在改/加任何功能代码前，一定要先想是不是要改或加test case。
• 测试驱动产生的单元测试代码是代替不了集成测试的，它还是单元测试
• 测完记得清理测试环境，还原到测试之前的样子

后面的文章我准备用VS2008来举简单的例子，还有一些测试的模式，测试的辅助工具...