测试驱动开发(TDD)跟敏捷开发有冲突

本文是从 TDD leads to an architectural meltdown around iteration three 这篇文章翻译而来。

---

     这些话来自于我们的软件领袖Jim Coplien―上世纪九十年代最流行的几本C++著作的作者。原话是这样的：

     严格的按照YAGNI原则的驱动测试开发(TDD)会导致敏捷开发3次迭代结构的坍塌。

    看到反TDD运动已经形成了一定的气候，真是让人感到非常的振奋，我特别喜欢Jim和Bob Martin 之间的争论，Bob Martin，这出了名的TDD极端主义者，认为任何一个程序员，只要所写的任何一行代码没有使用TDD，就不是一个专业的程序员。

    Jim 和 Bob 最近的一次非常有趣的辩论，你可以在InfoQ找到他们的辩论记录。我很敬佩Jim在面对Bob时表现出来的礼貌和克制，因为当你的观点和Bob不一致时，他的言论永远都让你难以忍受。

    TDD已经让我纠结了很久，你可以从InfoQ上发布的我的一场被叫做Designing for Testability的演讲，或从我最近和Hani Suleiman 一起合著的书里看到我对TDD的某些效果的质疑、甚至是反对。

    我已经说过，别指望我会跟Bob Martin 唱对台戏。我绝对没有意思说你要永远别使用TDD，但我相信，TDD所带来的好处被过度的夸大，软件社区的人需要明白，TDD只是一种工具，对于一种工具，并不是所有的情形下都会好用。我特别不喜欢TDD极端主义者们的四处鼓噪、妄图使那些没有使用TDD的程序员感到沮丧，或使他们认为他们现在开发软件所使用的方式有什么不对。

    如果让我说，我感觉大多数的TDD极端主义者在各种会议上说的太多太久了，已经不用动脑子就能举例写出一堆的用来计算保龄球得分的类和代码程序。而这些卡通式的小程序很容易，它们让TDD很风光。但是，当这些听众离开会场后挠着头纳闷如何让这种技术应用到自己的真实工作中时，你不要吃惊。如果你使用TDD去开发手机应用程序或去跟需要处理遍布3三大洲的上百万的两阶段提交事务的主框架进行交互的程序时，你算是撞上头彩了。

     我不知道你的感觉如何，反正我是有点厌倦了软件社区里的这种危言耸听―无论它是来自TDD狂热分子还是来自那些声称绝不招聘不使用Mac做开发的人的人。

     当需要进行测试时，我信守下面的经验主义的做法：

“先测试”还是“后测试”并不重要，只要你是在测试。

在你的开发过程中尽可能早的考虑测试。

不要让某个框框限制了你的行动。例如，不要轻信那些人告诉你的、要写出“尽可能简单的能够运行的程序”―也就是所谓的YAGNI―的话。如果你的经验告诉你，未来你会用到这个额外的类―虽然现在用不着，你应该相信你的判断，加上这个类。

记住，功能测试是真正对用户有意义的测试。单元测试只是为你―开发者―服务的。属于奢侈品。如果你有时间去写单元测试，那最好了：当你的程序出现问题时，它们能帮助你省去很多时间。但如果你没有时间，你要确保功能测试能覆盖到你的产品里用户所期望的所有功能点。

如果你没有做驱动测试开发，不要有任何的不安。有太多的因素都能导致这种开发方法在众多的项目和个人开发习惯中水土不服(有很多因素那些TDD极端主义者们永远都不会提)。

     不要让那些极端主义者把测试搞得痛苦不堪，如果你能运用自己的判断来实践它们，这将会成为你职业表现在最有价值的品行。