H.E.'s Blog

    设想把编程看成是转动曲柄从井里提一桶水上来的过程。如果水桶比较小，那么仅需一个能自由转动的曲柄就可以了。如果水桶比较大而且装满水，那么还没等水桶全部被提上来你就会很累了。你需要一个防倒转的装置，以保证每转一次可以休息一会儿。水桶越重，防倒转的棘齿相距越近。
　　
    测试驱动开发中的测试程序就是防倒转装置上的棘齿。一旦我们的某个测试程序能工作了，你就知道，它从现在开始并且以后永远都可以工作了。相比于测试程序没有通过，你距离让所有的测试程序都工作又近了一步。现在我们的工作是让下一个测试程序工作，然后再下一个，就这样一直进行。分析表明，要编程解决的问题越难，每次测试所覆盖的范围就应该越小。

     上文摘自《Test-driven developmen》  查看书籍:http://www.douban.com/subject/1230036/

==========================================================================================
我的一句废话：
TDD的指导思想是让你 通过测试 对你的项目中任务的风险进行分析，推动整个开发的进行。而不只是单纯的测试工作。
==========================================================================================
我有3个关于实施中问题：
    1.什么样的项目合适敏捷中的 TDD (测试驱动开发)
        有人说，任何项目都适合，TDD是一种弹性的方法。
        又有人说，并不是任何项目都适合，大项目更适合，小项目反而实践到最后让你想放弃。
        再有人说，如果说大项目适合，小项目就不适合？请问你界定项目大小的标准是什么？说清楚了，再说谁跟谁到底是不是合适。

    2.很多人没有这样的习惯，如何让他们养成这样的好习惯，一个公司上千人，一个部门上百人？怎么去推广？
        有人说，写着程序自动去检测他项目里面写的代码，发现没有按照规范去测试代码，就自动删除他的项目代码，并且报告项目经理。
        又有人说了，ok，我写，但是我测试的输入和输出标准是我自己定的，运动员和裁判员都是我，这样合理吗？
        再有人说了，任何管理手段都不能100%依靠工具，还需要人的干预，但又有什么办法一劳永逸并且让TDD手段一直被持续下去？

    3.当程序在每个人开发人员手里，并非完全由项目管理者掌控，测试覆盖的范围、粒度应该是多大？
        有人说，我可以认认真真的去测试，但是我的测试到最后才让我发现并不符合适当的粒度，精力白白浪费了怎么办？
        又有人说，你可以去先写文档具体到描述什么条件时以什么参数调用什么方法时会有什么返回值，先写文档再写代码的过程。
        再有人说，在我们上百人的公司里不会有人接受让程序员先写测试文档的，你的想法很好，但是很难推广。。。。。

上述所说，绝对不是空谈，正是很多公司想采用敏捷，想采用TDD，在实践的过程中遇到的一些冲突和常见问题。

先写到这里，有时间在继续写下去。

–end–