经验总结：JUnit实战
前言
由于现在公司进行Unit Test Case的整理阶段，所以抽空对Junit进行了一下了解，以下是集合了众家所长之精华（考虑的是按我的思路总结的，也许不能完全表达作者的思路，所以在附录中有所有我参考的文章地址，大家不妨去看看原文）。
一、测试的概念
长期以来，我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在终验收的时候编写测试文档，有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡UML、RUP、软件工程、CMM，目的只有一个，提高软件编写的质量。举一个极端的例子：如果你是一个超级程序设计师，一个传奇般的人物（你可以一边喝咖啡，一边听着音乐，同时编写这操作系统中关于进程调度的模块，而且两天时间内完成了！）。我真得承认，有这样的人（那个编写UNIX中的vi编辑器的家伙是这种人）。然而非常遗憾的是这些神仙们并没有留下任何关于如何修成正果的README，所以我们这些凡人－－在同一时间只能将注意力集中到若干点（据科学统计，我并不太相信，一般的人只能同时考虑多7个左右的问题，高手可以达到12个左右），而不能既纵览全局又了解细节－－只能期望于其他的方式来保证我们所编写的软件质量。
为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，终变成了一团乱麻。你可能会争辩，在这个例子中，设计很好的状态实际上并不好，如果好的话，不会发生你所说的情况。是的，看来你变聪明了，可惜你还应该注意到两个问题：1)我们不能指望在恐龙纪元（大概是十年前）设计的结构到了现在也能适用吧；2)拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响，即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能，那么你很可能失去了你的住房贷款和面包（对中国工程师来说也许是米饭或面条，要看你是南方人还是北方人）。
另外，需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味（不好意思...）。我希望看到这篇文章的兄弟姐妹能很容易地接受测试的概念，并付诸实施。所以有些地方写的有些夸张，欢迎对测试有深入理解的兄弟姐妹能体察民情，并不吝赐教。
好了，我们现在言归正传。要测试，要明白测试的目的。我认为测试的目的很简单也极具吸引力：写出高质量的软件并解决软件熵这一问题。想象一下，如果你写的软件和Richard Stallman（GNU、FSF的头儿）写的一样有水准的话，是不是很有成感？如果你一直保持这种高水准，我保证你的薪水也会有所变动。
测试也分类，白箱测试、黑箱测试、单元测试、集成测试、功能测试...。我们先不管有多少分类，如何分类。先看那些对我们有用的分类，关于其他的测试，有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何（How）完成功能和完成什么样（What）的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样（What）的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。
需要强调的是：测试是一个持续的过程。也是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说简单的:测试是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：
//将要被测试的类
public class Car
{
public int getWheels()
{
return 4;
}
}
//执行测试的类
public class testCar
{
public static void main(String[] args)
{
testCar myTest = new testCar();
myTest.testGetWheels();
}
public void testGetWheels ()
{
int expectedWheels = 5;
Car myCar =new Car();
if (expectedWheels==myCar.getWheels())
System.out.println("test [Car]: getWheels works perfected!");
else
System.out.println("test [Car]: getWheels DOESN'T work!");
}
}
如果你立即动手写了上面的代码，你会发现两个问题：
第一，如果你要执行测试的类testCar，你必须必须手工敲入如下命令：
[Windows] D:>java testCar
[Unix] ％ java testCar
即便测试如例示的那样简单，你也有可能不愿在每次测试的时候都敲入上面的命令，而希望在某个集成环境中(IDE)点击一下鼠标能执行测试。后面的章节会介绍到这些问题。
第二，如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准。没有人希望查看别人是如何设计测试类的。如果每个人都有不同的设计测试类的方法，光维护被测试的类够烦了，谁还顾得上维护测试类？另外有一点我不想提，但是这个问题太明显了，测试类的代码多于被测试的类！这是否意味这双倍的工作？不！
1) 不论被测试类－Car 的 getWheels 方法如何复杂，测试类－testCar 的testGetWheels 方法只会保持一样的代码量。
2）提高软件的质量并解决软件熵这一问题并不是没有代价的。testCar是代价。
我们目前所能做的是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。好IDE工具可以支持这些规范。好了，你所需要的是JUnit。一个Open Source的项目。用其主页上的话来说是：“ JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。用于Java开发人员编写单元测试之用。”所谓框架是Erich Gamma 和 Kent Beck 定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。通过回归测试我们抓住了这条大Bug。
