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，如果你的客户和老板都不准备买
单，那么就自己买单。你应该相信，微小的付出，会换来更多的价值！