工具能帮助我们减少测试驱动开发的工作量吗？

随着像 Agitar One 和 Parasoft’s JTest 这样高质量测试代码生成工具的出现，很多人开始质疑，是否还有必要手动编写测试代码？ Bob（Martin）大叔深入剖析了这种想法的弱点，给了它重重一击。

这些工具是被设计用于检查已有代码块的，它将以分支、循环等为基础，综合生成一套针对代码的观测报告，开发者可以通过审查这些报告，选择为自己关心的部分 生成整套的测试用例。对于遗留代码，这种方式是了解已有行为的一种非常有效的方式，让开发者可以在进行改变之前，先创建一张安全网。

然而，任何技术都是有限制的：这些工具只是针对代码生成一套观察报告，它们并不能理解算法或是开发者的意图。下面是来自 Bob 的说明：

作为一个简单的示例，我试着使用两款知名的测试生成工具来为保龄球游戏程序生成测试代码。保龄球游戏的接口看上去是这样的：

public class BowlingGame {<br></br> public void roll(int pins) {...}<br></br> public int score() {...}<br></br> } 设计思想是：在每次投球后调用 roll 方法，在游戏结束后调用 score 方法得到本次游戏的得分。 显而易见，测试生成器并不能随机生成有效的游戏。一次有效的游戏应该是一个有 12 到 21 次投球的序列，每次投球得分应该在 0 到 10 之间，还有什么？那就是 在每一格内，投球的得分总数不能超过 10，对于处在目前阶段的随机生成器来说，要实现这些约束条件确实太困难了。

另一个方面，测试驱动开发（TDD）要求先写测试、再写产品代码的工作方法与众不同。TDD 能起到作用，那是因为它会对开发 人员编写的代码进行即时的反馈。在做出任何小修改后，只要运行测试，开发者就可以知道这些改变是否正确；TDD 确保了代码与我们通过测试代码表达的意图是 相匹配的；TDD 让我们以一个消费者、而不仅仅是创造者的角度来思考如何设计代码，它让我们针对每一个条件和回路进行思考；而且，就像 James Carr 提到的那样， TDD 迫使我们去考虑代码耦合的程度，看看 Bob 对此又是怎么说的：

使用测试生成器破坏了这个原则，因为生成器是以产品代码作为输入来生成测试的，而且因为它是全自动转换的，所以其生成的测试代码也不便于阅读。人类的意图 只是通过产品代码进行了体现，而无法通过阅读所生成的测试代码来获得验证，更无法通过它来确认产品代码是否已经实现了人类的意图。虽然人类会去检查自动生 成的报告，但相比 TTD 而言，这只是一个很被动的行为，远不及 TTD 对于缺陷、设计和意图体现上的洞察力。

……这并不是在说测试代码生成器没有用……我想它们有助于部分标识出大量遗留代码的特性。

查看英文原文： Can Tools Reduce the Effort Involved in Test Driven Development?