TDD，想说爱你不容易

    TDD，也就是 Test Driven Development--测试驱动开发，其实是一种开发方式的巨大提高。它
提出了一种新的开发方式：以测试为驱动。在此，我仍然想引用一个曾经看过的ThoughtWorks的
一个人的Blog中的一句话：“什么是TDD？TDD就是把你的需求用测试给描述出来。”这句话一下
子让我明白了TDD的意义，并且被我个人奉为TDD中的经典 :)

    归根到底，TDD的实质仍然是以需求来驱动开发，只是，TDD中把需求进一步写成了测试，那
就成了测试驱动开发了。

    这么做的好处是什么？我想至少有以下这么几条：

    1、你的代码是可测试的。
    2、你的代码完全反应了需求。
    3、通过测试驱动，会规范你的代码和结构，甚至架构。

    不错，我承认，TDD会带来成本的提高。因为我们要写测试，所以必然要花费时间。那么这部分
的成本谁来买单呢？客户吗？这很难，因为毕竟大部分的客户已经在软件的本身就和你讨价还价
了，你还想让客户再为测试来买单？

    让老板买单？老板恐怕要为此付出加班费。舍得，还是舍不得？这似乎又变成了一个哲学的问
题。

    自己来买单？也就是自己白加班来做这些事。值得，还是不值得？这似乎又是一个职业态度的
问题。

    如果单从理论上，每种买单方式都可以写厚厚的文字去论证，不过这么做其实并没有很大的意
义，我还是从实践中说起。

    就说最近的两个项目。一个是公司的移植项目，从一个专有的framework移植到structs；另一个
是我帮助朋友做的一个国内的小项目。第一个项目，我说了不算；第二个项目，我的意见起主导
作用。

     移植项目的团队中一共有10个人。我使用了Selenium这个工具。但因为是移植的项目，所以
TDD的概念也就无从谈起。不过，每移植一个功能之前，我都是先按照旧系统的操作，使用
Selenium来编写测试类。在功能移植完毕之后，我在新系统中去跑我的测试类。

    因为需要测试的内容非常多，所以，我的测试方法也是越写越多，其中不停的重构和修改，也
总结了一些简单的测试方式。

    是的，最开始，我花的时间确实比别人多一点，多多少呢？？一个测试方法，我相信我用10分
钟就足够写好了。重构？我想1，2个小时足够了。

    而且，我每次修改完一个功能，我可以运行全部的测试，这样，我就知道我的修改对以前的改动
是不是造成了负面的影响。

    一个月下来，我能运行的测试类有140多个，需要注意的是，我并非写了140个测试方法，因为
有的测试类是通过继承来实现的，这是因为有许多画面，可能就是商品种类不同，剩下的都相同。

    这样，每次系统改动的时候，我只要把这些测试全运行一次，就知道我负责的模块是不是有问
题。

    那么其他人呢？他们仍然在手动测试，每次一个更新，他们都要手动去测试每一个地方，而且
不能保证测试到了每一个地方。

    那么我来计算一下成本吧！就算我那140个测试方法都是单独的，每个方法我需要10分钟，
那么我需要 1400 分钟，1400/60 = 23.3 个小时。也就是说，一个月下来，我只需要多付出23.3个
小时。

    那么收益是多大呢？一个月后，我只需要20分钟就可以知道系统是不是存在错误，而他们却
需要几个小时，而且未必准确。

    再来说说那个国内的项目。那个项目我要求了使用TDD的方式，因为这是一个从零开始的项
目。在实现一个功能之前，首先编写测试方法，确定了这个功能要实现什么目标，如果有错误，
该提示什么样的错误信息。

    根据经验，一个测试方法大概需要10-20分钟，到目前为止，大概完成了25%，一共有40个测试
方法，那么成本就是 400/60 = 6.7 个小时。收益呢？目前只要做了任何一个改动，只要跑一遍测
试，就可以知道系统是不是存在问题。

    我通过了2个实践的例子来说明TDD的优势，其实归根到底，TDD从开发方面，节省了我们的
测试资源，从用户方面，保证了产品的质量，从老板的角度来说，其实是用小的成本换来大的收
益---为什么这么说？小的成本其实就是测试方法的编写，大的收益就是产品质量的保证，以及更
好的产品，吸引来更多的客户。

    但是，就是这么一点点的成本，或许是再稍微多一点的成本，让很多公司望而止步。很多人仍然
认为这些成本可以省掉。因为理由很充分：你看那么多公司，不是仍然效益很好，顾客很满意吗？
其实如果深入到那些公司内，就会发现：维护的项目是多么的糟糕，每次Release，如何保证这次
的改动不会造成影响？除了让QA的人测试大量的case，还有别的办法吗?

    “我们修改了一个bug，但同时又创造了一个新的bug。”这个神话不是我们自己创造的吗？

    我想TDD还有漫长的道路需要走下去，需要更多的时间来获得人们的认同，只是目前的情况，
只能是TDD，想说爱你不容易！

    如果你是一个准备购买软件的客户，那么你可以毫不犹豫地要求软件开发商使用TDD的方式，
因为你应该知道这样做其实是在保护你的利益。

    如果你是一个老板，那么你应该立刻要求下属学习并实践TDD，如果客户不买单，那么你应该
买单，因为你应该相信，微小的成本会换来更好的软件，更好的软件会迎来更多的客户。

    如果你是一个开发人员，那么你应该立刻学习并实践TDD，如果你的客户和老板都不准备买
单，那么就自己买单。你应该相信，微小的付出，会换来更多的价值！

很受触动，最近一直关注单元测试，这篇文章应该是测试类文章里写得比较言之有物的佳作。
我不太明白的是，比较大型一点的项目用TDD方式是否合适呢？例如15个人以上的项目，从头开始，用TDD的方式能否把所有的需求表述清楚？这种方式岂不是不用产生文档或者极少量的文档？有的客户对文档是很看重的。其实归根结底，还是我对TDD的具体应用不懂，对TDD只有概念性的了解，所有对它到底能发挥什么程度的作用没有信心。
TDD，我的努力方向。。。
希望有更多的们介绍介绍TDD的具体应用方式。

做不比做好，多做比少做好
用什么方式能够把所有的需求表述清楚？

这不是TDD的问题，是实践TDD的人的问题。


从来没人说过有了TDD就不用写文档，其实事实是应该先有文档，
然后才会根据文档来写测试方法。



你可以实践一下，不会浪费你很多时间，只需要一个月，你就会体会
到了。

TDD 本来就是风险驱动,将本求利.
觉得核算就做,不核算别做就是了.

我和你也有同样的考虑
希望对TDD有更多的了解

TDD和需求没啥关系，两者之间相差很远。TDD之和程序员如何实现一个自己的想法有关。

方法很多，就看哪个适合。。。

小项目用tdd貌似是浪费。
但如果迭代次数十几次或者几十次，或者一个流程的功能点是很复杂的一串的时候，就会惊讶tdd居然能节约那么多时间。

我看到的说法都是用test描述需求，然后写实现。怎么说TDD和需求没啥关系呢？

TDD，Test Driven Development--测试驱动开发，既然是测试驱动，那么，TDD就和需求关系紧密，至少距离需求比较近，而不是传统的那些开发过程，测试排在最后。

软件最终由程序员写代码实现，所以程序员需要理解需求，实现系统功能，把问题解决在自己的范围之内，因此是不是测试驱动开发，程序员自己的测试都很重要，而测试驱动开发就更向前走了超前的一步，保障软件的质量，开发的效率。

TDD应该是离不开相应的文档的，需求说明、系统设计、UML等相关的文档离不了，因为需要进行项目中和项目外的沟通协调工作。只不过是地位下降，不是开发中主要的部分。

至于风险，应该说随着软件开发方法、开发过程理论实践的不断发展，风险是逐渐下降的，也就是说，使用传统的开发过程，风险可能会更大。能够起到多大的作用，提高多少效率，存在多大风险，在于使用TDD的开发者的水平。