TDD，让我轻轻地靠近你

    TDD这个东东吵吵嚷嚷好多年，但是实践起来就是那么的难，这也是没办法的事--项目已经很紧张了，我们为什么还要花时间在写测试上面？

    这么说吧，TDD就好像是一个美女，看着确实很漂亮，可是追到她却需要很大的本钱。好吧，我也不心急，先让我轻轻地靠近你。

    那么在对日项目中实行TDD似乎更是难上加难了？因为对日的项目很注重设计文档，他们称之为“详细设计”。详细到什么程度？详细到变量的名字都起好了，写代码的时候，只要照着文档写就可以了---这其实是个神话，也确实是个神话。为什么呢？我从来不相信有哪个人能凭空想象就把一个复杂的功能设计的如此完美。事实也确实如此。
    问题出现了，你想用测试来描述需求，人家不给你这个机会，设计文档都作好了，还用你来用测试去描述需求？而且那些项目的头头都有10几年的经验，TDD？人家可不管这个，现在这个模式最好了，10几年都没出过错！
    好吧，似乎我和TDD的缘分也就到这里了，我一个人力量实在太弱小，难道我要从此随波逐流？不是很甘心，“爱美之心，人皆有之”，所以我决定换个思路。

    ok，项目的管理方式早就是定式，既然任何人都难以改变，那么我就遵循他。其实写那个所谓的详细设计也并不是一点好处都没有，至少可以锻炼你的抽象思维。这个时候，我没有和任何人提起过TDD这三个字，更没有向领导强烈要求要实行TDD。
    当设计进行到80%左右的时候，我开始编写代码了。同样，我没有告诉他们我正在从测试类写起，虽然测试反映的是详细设计的内容，不过那没有关系，因为详细设计反映的也是需求的内容。这个时候我也没向领导说我已经开使TDD了。

    终于，详细设计结束的时候，我的代码也完成50%左右了。我每天都在写代码，领导当然不可能看不到，这个时候过来问我写到什么程度了，我也只是说完成了多少。至于TDD？一个字都没提。

    大伙终于开始全部编码了。因为我是最早开始进入开发环境的，所以这个时候我就需要把开发环境和注意事项给大伙讲一下。我告诉他们如何配置环境，到代码的部分时，对经验还不是很丰富的同事说：一定要先写测试类，这样可以帮助你理清楚逻辑。对于比较有资历的同事说：可以先从测试类写起，你看我们都写这么多了。TDD？一个字都没提。

    到项目快结束的时候，我们的测试方法达到了80多个。按照我以往的经验，测试方法在10几个，20几个的时候，测试方法的作用不是很明显。当达到50个以上的时候，其中一个重要的作用就会体现出来了：持续集成。

    也就在这个时候，我们需要进行一个大的改动，数据库操作层里的很多方法，都需要修改返回值。这是一个非常大的改动，很多地方都影响了逻辑层里的处理方式。

    不过，我一点也不担心。当大伙修改完毕，我跑了一下全部的测试，结果发现有几个case没有通过。赶紧找原因吧。原来是逻辑层里的某个地方在修改的时候出现了空指针的代码。

    通过这次的改动，让大伙见识到了TDD的威力，之后，大伙对测试类的维护也很用心。

    之后的之后，还有很多次的修改，每一次都是通过测试来发现了一些问题。修改了N次之后，我一点都不担心质量的问题---因为所有的测试都能通过！

    ok，直到现在，我仍然没有提过TDD的一言半语，只是和领导在项目总结的时候提了一次。而且，到目前为止，代码的质量能够得以保证，对于每个人来说也是一个激励，也为下一个项目能坚持写测试注入了一点的动力。

    有一次进行一个比较大的改动，对于其中一个改动，我问一个同事：“你这么改难道不会出错吗？”那个同事说：“如果出错的话测试应该能跑出来吧，现在测试都能跑过去。” 我反过来被教育了一次，不过我很高兴。

    虽然如此，TDD仍然很难被大部分人接受，我仍然不会提TDD三个字，TDD这个美女太漂亮，提出来难免会激起大家心中的各种波澜。
    暂时，还是先让我轻轻地靠近你吧。

从开始付诸实践到项目组基本都掌握了，楼主用了多长的时间？

也就是项目的开发时间，大概1个半月。
不过，现在并不是“项目组基本都掌握了”，少数人可以认可，大部分人还难以接受，
呵呵。

下一个项目，我的打算是先让大家有持续集成的概念，然后更大程度的使用TDD。

楼主讲得十分不错.我深有感触阿.增经干过不少拆东墙,倒西墙的事.不知道楼主测试主要是针对那一层进行?(dao,service,action) 或者是都包括了?

我只是针对业务层和数据操作层做了测试，因为项目是application的，所以UI部分没有做。

测试不是为了证明代码没有问题，而是说明某个问题有没有再出现。
楼主的情况说得有些理想化。

方法不错，，，呵呵。。。。实质是TDD就ok，，，名义上怎样，，不care

应用TDD，有不同的层面，首先是个人的TDD，然后才是团队的TDD。楼主讨论的主要是如何在团队中应用TDD。

确实，比起一个人来说，让更多的人去采用一种新的方法，本身是很难的，尤其这种方法涉及到与人原有技能并不一致的时候，尤其像TDD这种从小规模上看不出什么效益的方法。

楼主做得不错，名字并不重要，通过自己的实践，让别人看到这么做的价值所在，他们就会逐渐相信这种方法。

关于测试驱动开发，最近刚好写了一篇blog，讨论了一下个人在实际工作中遇到的一些问题。
实践测试驱动开发

赞同。而且我觉得说TDD的很多人都对单元测试所能达到的效果有一些夸大。

如果能简单的介绍一下怎么做的就好了....