TDD的误解

前几天看到一篇《都在说TDD开发,那到底TDD是什么?》,感觉这个作者根本就没明白什么叫TDD。

TDD还远达到如作者所说的“过份强调”的程度,甚至应该说还强调得不够。不可否认,“高质量的程序是程序员编写出来的,而不是测试出来的”,但是如果没有有效的测试手段,如何能够客观地判定一个程序是不是“高质量”的。

至 于认为TDD会导致程序员变成代码工人的说法更是无稽之谈。TDD的Test case只负责检查某个功能是否得到完整正确的实现,至于如何实现的细节依然是掌握在程序员手中,他们完全可以充分地发挥他们的创造力。从某种角度上说, TDD不但不是束缚,反而是一种解脱,因为有TDD作保障,程序员可以更加放心大胆地去创造。

那么TDD是否会增加工作量?表面上看是这样 的,因为需要额外的精力去编写Test case。但是只要真正实践过TDD,就会发现Test case的编写远比实现具体功能要容易得多,增加这少量的工作量可以换取如Debugging之类的工作量的大量减少,总的来说反而是减少了不必要的工作 量。

测试用例的错误和失误风险和程序的风险等效”? 这又是一个对测试的误解。Test case的本质是需求的代码表达,写出正确的Test case的基础是对需求的准确理解。而如果Test case错了,说明对需求的理解就是错误的,那么即使不写Test case直接编码的话,不论这个代码写得多么完美,它不能正确地实现需求,结果不过是一堆废品。Test case的编写恰恰能够在很大程度上防止这种需求错误的风险发生。

对于重构来说,TDD更是不可或缺的保障。每个程序员都希望能够一次就把 代码写好,但现实是残酷的,一个功能的第一次实现通常都是看上去很美的,但是面对需求的变化以及对软件的强壮性、安全性、灵活性的要求,修改代码不可避 免。既然修改不可避免,那么重构就不可避免,如果没有TDD,如何能够保证重构以后的代码所实现的功能与原来一致呢?

版本升级意味着需求的 变化,Test case必然也要跟着变化,按着TDD的思路做来,就必须保证Test case与实现代码的同步,否则就不是TDD了。相对于文档来说,写Test case同样是写代码,对于程序员来说,这种同步工作相对来说更容易被接受,所以保持同步的难度也小一些。至于说ugly的Test case与滥文档一样,这点我同意,不过如果一个程序员写的Test case很滥的话,那也就不要指望他能够写出什么sexy的实现代码了。

Thinking-driven Development的说法固然没错,但有什么事情不是Thinking-driven的呢?这种空话没有一点可操作性,说了也是白说。

很多人对一些新生事物还是充满了误解和偏见,比如这篇《我之所以站出来骂RoR》。其实不论是TDD还是RoR,都不是靠骂别人而起来的。