程序员实用测试技巧(1)

     如果要写JUnit测试代码，应该从哪里开始呢？

    本书的第一部分为有效的使用JUnit设计和测试Java代码奠定了基础。一旦你能理解这部分介绍的技巧，并能熟练地在实际工作中应用它们，你就会永远使用下去——因为所有的测试，其实都可以分解为后面几章中将要介绍的一个或者几个技巧。问题在于，你如何在工程级的特定Java应用的代码和类结构中，认出这些简单的小模式。因此，在对付大的问题之前，让我们首先处理这些小问题。

    到第1部分结束的时候，你将学习到60多个重要的JUnit技巧，它们涵盖了测试的各个方面：编写、组织、创建和执行测试，还有如何维护测试数据以及如何汇报测试结果。第2、第3部分的技巧经常会用到第1部分介绍过的技巧，因此请做好随时回头查阅的准备。很快，你就会对这部分介绍的技巧非常熟悉。

本章主要内容：

■   有关程序员测试的介绍

■   JUnit入门

■   JUnit的一些经验之谈

■   什么时候使用测试而不是调试

我们痛恨调试程序。

你抬头看看墙上的钟，发现已经很晚了，因为今天晚上还有一堆的错误需要纠正。现在已经到了“编码与纠正”阶段的纠正部分了，并且这个阶段已经持续了三个月。到了这个时候，你可能几乎已经忘记你们家是什么样的了。你现在比以前任何时候都熟悉的是办公室的四面墙­——假设你真的有四面墙可以看到。当你盯着“关键错误”列表的时候，发现有一个问题又回来了，你还以为一个星期前就已经解决了呢！这些该死的测试人员什么时候能够让你安静一会儿呢！

先启动调试工具，再启动应用服务器——赶紧呷一口咖啡，你可能只有5分钟的空闲时间——然后你需要设置一两个断点，在10个文本区输入一些数据，然后点击“GO”按钮。调试器会在第一个断点停下来。你的目的是找到哪个对象老是产生错误的数据。当你一步步地调试代码的时候，偶尔性的肌肉痉挛——明显是睡眠不足造成的——会让你忽略那些可能产生问题的代码。现在你必须将应用服务器停下来，重新启动调试器，再重新启动应用服务器。利用这个间隙，抓起一块已经变味的糕点，喝下六个小时以前冲的苦咖啡。这样的工作有意思吗？

哦不！就算最有毅力的人也会说，“我宁愿做一个测试人员！”

1.1  What is Programmer Testing什么是程序员测试

程序员测试并不是对程序员进行测试，而是有关程序员所进行的测试工作。近几年，一些编程人员发现如果自己去编写测试程序会带来很多好处，这种好处是以前“让测试部门来管”所 没有的。修正错误非常困难，主要是因为花时间太多：不仅测试人员需要花很多时间来发现错误，并且要给程序人员提供足够的信息来重现这个错误；编程人员也要 花费很多时间，从几个月前看过的代码中找到错误产生的原因。还有很多时间花在讨论这些究竟是不是一个错误，弄清楚为什么程序员会犯如此幼稚的错误，是不是 测试人员干扰了他们的工作？是不是需要让测试人员远离程序员而不去打扰他们等等。如果程序员自己测试他们自己的代码，那么就可以节省很多时间。

    程序员所做的测试一般叫做“单元测试”。但是我们在这里不想使用这个词语，因为这个词被过度地使用和滥用，通常它带来的混乱比它所能解释的意思还要多。在程序员社区中，我们不能统一地确定“单元”是什么——是一个方法吗？是一个类吗？还是一段代码呢？如果我们不能就“单元”达成共识，那么就不用说“单元测试”了！这也是为什么我们使用“程序员测试”来表示程序员自己所做的测试工作。这也是我们为什么使用“对象测试”来表示对单独对象的测试。将不同的对象隔离开单独测试，是这本书中主要涉及到的测试方式。也许这和你所想象的测试工作有出入。

有一些程序员是这样测试他们的程序的：先在某些特定的行上设置一些断点，然后再将应用程序运行在“调试”的模式上，一行一行地步入他们的程序，并且检查相应变量的数值。严格地说，这就是“程序员测试”。因为这是程序员在测试自己的程序。但是这样做会带来很多缺点，包括；

    需要调试工具，这并不是所有的人都已经安装或愿意安装的。

    在执行测试以前，需要有人去设置断点；在测试完成以后再将这些断点去掉。如果要进行多次测试的话，这样做非常麻烦。

    需要知道和记住这些变量所希望的数值。这就使得其他人来执行这些测试非常困难，除非他们能够知道和记下同样的数值。

    想要测试任何的代码片段，就必须了解整个应用程序是怎样工作的，需要花一段漫长的时间来进行一系列键盘的输入和鼠标的点击。这会使一个测试的执行过程非常容易出错。 

原文转自：http://www.ltesting.net