译释Dozen ways to find bugs(2)——Stop Debugger Testing

      英文原文名叫《A Dozen Ways to Get the Testing Bug in the New Year》，是Aaron在java.net上发现的文章。原文地址http://today.java.net/pub/a/today/2004/01/22/DozenWays.html，原文是在2004年1月22日发表的，按常理说一片早已经过了时效期的文章是没有多大用处的，但是Aaron却认为时至今日该文依然值得一阅。

      以下内容为Aaron遵照原文转译而来，如有翻译错误和纰漏，欢迎留言批评斧正。

——————————————————————————————————————————---------------—————————————————————— 

 以前有这么一段时间，我跟当时大多数程序员一样，利用调试器来调适自己的代码。这样做我就可以检查自己的代码了，不是吗？利用调试器，看起来的确是个不错的主意，美中不足的是它要求我们不能频繁地更改自己的源代码，否则这样或者那样的问题就出现了（如果每次更改都重新调试一次，我想没有比这更痛苦的事情了，而且如果我们只是调试我们自己改动的那一部分代码，我们就放过了代码更改引发的其他模块的bug，这样子会很糟糕，Aaron注。）慢慢地，我开始讨厌修改自己的代码了——每次更改都意味着我要重新把那繁琐的调试过程再进行一次。使用调试器运行回归测试跟使用main（）方法来做测试驱动（Test Driver）具有一样的缺陷，即每次代码的变更都会引起调试或者main（）方法测试的重新运行并且我们只能靠手工的方式来检查结果的正确性。这些原因会导致我不愿意修改源代码，接着就是看着代码慢慢地腐烂了（跟敏捷开发中说“代码有了坏味道”有异曲同工之妙啊， Aaron注）

如果你曾经也使用过Debugger来验证断言（Assertions）的，那你应该知道整个过程大概是这个样子的：

1.       在你认为必要的地方或者觉得有问题的行前设置一个断点

2.       对该行中某些感兴趣的变量添加监视

3.       运行应用程序至断点处暂停

4.       单步调试并沿途检查相关变量的值的变化

5.       有时候我们可能还会控制一些变量并迫使程序按照我们指定的路径运行 

在整个过程中我都在做这些事情，我满脑子都是各种各样的变量值，各种各样的期望值，各种各样的函数的实际输出值。调试器给出一些运行相关的信息，我再拿这些信息跟自己脑袋里装的某个期望值进行对照，这实际上是在做人工的对照和检查，这样的结果是让人感到厌倦并随之带来更多的错误。

对于我们来讲，我们需要的是可以帮助我们运行应用程序并自动做出结果比较验证的自动化测试，而不是使用调试器调试这种实际上仍然是人工的不准确的方式来验证我们的程序。我们应该知道，单单因为需要几小段待测代码而搭建一个自动化测试框架并不是一件简单可行的事情。毕竟，它只是帮助我们运行了几段代码而已——但是，如果代码会改变，那么我们就值得为之而付出。我们会发现，（运行自动化测试）会帮助我们减弱待测代码对于其相关代码的依赖性（运行自动化测试本身的成本是很低的，不用像调试那样每次付出很多的精力和时间，因此待测代码相关的代码发生改变之后，我们只需要运行之前的测试代码就可以了解是否对待测代码产生了不好的影响，而不用大规模使用调试器来验证所有相关联的代码甚至是全部代码，Aaron）。