本文共 1287 字，大约阅读时间需要 4 分钟。

    软件构建学问中总有一些理论上很美好，但是一使用就面目全非的东西，比如传统的瀑布模型。敏捷里很多被称之为思想的东西，恰恰没有太高深的理论，但都是一些实践的艺术，强调动手做而不是用理论论证。TDD就是这样一种东西，单纯去研究它的理论，分析它的优点和缺点没有任何意义，因为它本身就是一个很单纯的东西，再对其抽象也得不出象“相对论”那样深厚的理论。问题是你做了没有？支持TDD的人有没有从实践中真正体会到了它的优点，对TDD不屑一顾的人是否通过实践验证了自己的看法，而不是简单的人云亦云？     我第一次实践TDD是在做“TMS 配置数据转换工具”时进行的，在那之前其实已经注意TDD的很长时间了，但是一直无从下手，感觉有很多“实际”问题没有头绪，比如“测试用例的粒度怎么确定？”，“是否是一个测试用例对应一个测试函数？”，“函数还不存在怎么调用，怎么传递参数？”等等。在做的时候才发现，其实所谓的“实际”问题只有在做的过程中才变得真实（也就是真正的实际问题），真实的问题通过努力就可以解决，如果不去实践，只能是越想越困惑。          通过几次“摸着石头过河”般的尝试（有成功的，也有失败的），我对TDD的认识开始从感性向理性转变，开始有了实质性的感觉，对于原来想象中的一些问题也积累了一些解决方案。我开始飘飘然，觉得TDD不过如此，so easy！直到后来有机会和邓辉一起用TDD对系统中一个模块重构时，我才发现我对某些方面的错误认识导致了一些错误的方法。通过两天的结对编程，以前实践中的一些错误做法，这一次都被邓辉纠正了。比如我以前喜欢先写一个空函数，定义好参数类型等信息，然后回过头来再写测试用例，我之所以这样做的原因是希望代码在TDD的过程中随时可以得到一个可编译通过的结果，但是邓辉认为在写那个空函数的时候就会不由自主地产生一些关于实现这个函数的想法，这些想法就会对编写测试用例产生影响，会约束编写测试用例时的思维空间，所以应该抑制住写代码的冲动，坚持先写测试用例。再比如，我以前针对某个函数写测试用例的方法是一次写完这个函数的全部测试用例，然后再去完成代码，直到代码满足所有针对这个函数的测试用例。邓辉认为要写一个测试用例，写一点代码满足这个测试用例，然后再写一个测试用例，再写一点代码满足这个测试用例，循序渐进。为什么要这样繁琐呢？因为这样做实际上缩短了反馈时间，实现代码时发现有问题就可以及时重构，对已经完成的测试用例影响比较小，等所有的测试用例都完成后再实现代码，这个反馈周期就太长了，一旦需要重构就会影响到所有的测试用例。     总结在软件构建过程中使用TDD的经验，我的体会就是只有通过实践才能真正了解TDD。对着很多理论空想只能使自己迷惘，迷惘的原因是知道自己不知道，却不知道自己不知道什么。只有在实践中遇到问题，才知道自己不知道什么，这是好事，因为对解决问题有了努力的方向。第一次实践TDD可以从简单开始，不一定要用xUnit之类的测试框架，使用简单的assert（断言）函数就行了，也不需要太大的规模，对一个函数TDD就够了。所以，实践TDD，就从你要完成的下一个函数开始吧。

转载地址：http://tjcgj.baihongyu.com/