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

作者 Mark Levison 译者 张海龙 发布于 2008年1月30日

领域

过程 & 实践,

语言 & 开发

主题

质量交付 ,

工件和工具 ,

质量 ,

工具 ,

测试驱动开发 ,

软件工匠 ,

测试 ,

敏捷

分享到

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

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

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

 public class BowlingGame {
 public void roll(int pins) {...}
 public int score() {...}
 }

设计思想是：在每次投球后调用roll方法，在游戏结束后调用score方法得到本次游戏的得分。

显而易见，测试生成器并不能随机生成有效的游戏。一次有效的游戏应该是一个有12到21次投球的序列，每次投球得分应该在0到10之间，还有什么？那就是 在每一格内，投球的得分总数不能超过10，对于处在目前阶段的随机生成器来说，要实现这些约束条件确实太困难了。

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

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

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

1. 返回顶部

   当然不会！

   发表人 han isaac

   关于TDD中的测试，其真正的价值在于“写”测试的过程，而不是“有”一堆测试。不过，Agitar One这样的工具仍然很棒，它可以帮助我们为遗留代码构建安全网。

   回复

2. 返回顶部

   Re: 当然不会！

   发表人 陈 之过

   关于TDD中的测试，其真正的价值在于它是对运行代码的说明和监督.所以说它应该有两方面的作用,而tdd中更加强调对代码说明的部分,通过先写测试,来达到对代码说明得更明确的目的.而工具生成的测试则对代码是说明方面基本没有任何意义.
   不能了解代码的作用,而对代码的测试,是毫无意义的
   而且这样重构也不可能很好的进行了,如果不进行重构,那么要那个安全网还有什么用处呢?

   回复

3. 返回顶部

   Re: 当然不会！

   发表人 曾 庆锐

   to Chen Zhiguo
   
   也不尽然！
   
   如果工具能感知代码的重构，并在某一事件(按钮，菜单)的触发下，合理的重构测试代码，我想这个价值还是非常可观的。

   回复