JUnit实战

核心提示：前言 由于现在公司进行Unit Test Case的整理阶段，所以抽空对Junit进行了一下了解，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。

二、JUnit简介及为什么要使用JUint

JUnit就是对程序代码进行单元测试的一种Java框架。通过每次修改程序之后测试代码，程序员就可以保证代码的的少量变动不会破坏整个系统。要不是有Junit这样的自动化测试工具，代码的的反复测试简直会把人累死而且还可能不准确。现在好了，测试过程可以频繁进行而且还是自动的，所以你可以令程序错误降低到最少。它写的是单元测试（Unit Test）：软件工程里的白盒测试，就是测试某个类的某个方法的功能。XP 中推崇的 test first design 就是基于以上的技术。

假如你要写一段代码：

1. 先用 junit 写测试，然后再写代码

2. 写完代码，运行测试，测试失败

3. 修改代码，运行测试，直到测试成功

假如以后对程序进行修改，优化 ( refactoring )，只要再运行测试代码，假如所有的测试都成功，则代码修改完成。

Java 下的 team 开发，一般采用 cvs(版本控制) + ant(项目治理) + junit(集成测试) 的模式：

1. 天天早上上班，每个开发人员从 cvs server 获取一个整个项目的工作拷贝；

2. 拿到自己的任务，先用 junit 写今天的任务的测试代码；

3. 然后写今天任务的代码，运行测试，直到测试通过，任务完成；

4. 在下班前一两个小时，各个开发人员把任务提交到 cvs server；

5. 然后由主管对整个项目运行自动测试，哪个测试出错，就找相关人员修改，直到所有测试通过。下班...

先写测试，再写代码的好处：

从技术上强制你先考虑一个类的功能，也就是这个类提供给外部的接口，而不至于太早陷入它的细节。这是面向对象提倡的一种设计原则。好的测试其实就是一个好的文档，这个类使用者往往可以通过查看这个类的测试代码了解它的功能。非凡的，假如你拿到别人的一个程序，对他写测试是最好的了解这个程序的功能的方法。 xp的原则是 make it simple，不是很推荐另外写文档，因为项目在开发过程中往往处于变动中，假如在早期写文档，以后代码变动后还得同步文档，多了一个工作，而且由于项目时间紧往往文档写的不全或与代码不一致，与其这样，不如不写。而假如在项目结束后再写文档，开发人员往往已经忘记当时写代码时的种种考虑，况且有下一个项目的压力，治理人员也不愿意再为旧的项目写文档，导致以后维护的问题。没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改动会带来其他地方的错误。为此，除了设计好的结构以分割项目外（松耦合），但假如有了测试，并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要重新运行测试代码，假如测试通过，也就保证了修改的成功，假如测试中出现错误，也会马上发现错在哪里，修改相应的部分，再运行测试，直至测试完全通过。

软件公司里往往存在开发部门和测试部门之间的矛盾：由于开发和测试分为两个部门，多了一层沟通的成本和时间，沟通往往会产生错误的发生。而且极易形成一个怪圈：开发人员为了赶任务，写了烂烂的代码，就把它扔给测试人员，然后写其他的任务，测试当然是失败的，又把代码拿回去重写，而且在国内往往一个软件公司技术最差的部门就是测试部门（好的人都跑去写代码了），测试就成了一个很头疼的问题。这种怪圈的根源是责任不清，根据 xp 中的规定：写这个代码的人必须为自己的代码写测试，而且只有测试通过，才算完成这个任务（这里的测试包括所有的测试，假如测试时发现由于你的程序导致别的模块的测试失败，你有责任通知相关人员修改直至集成测试通过），这样就可以避免这类问题的发生。

三、安装

1. 获取JUnit的软件包，从Junit(http://www.junit.org/index.htm或http://download.sourceforge.net/junit/)下载最新的软件包。这里我使用的是http://download.sourceforge.net/junit/junit2.zip。

2. 将其在适当的目录下解包（我安装在D:\junit2）。这样在安装目录（也就是你所选择的解包的目录）下你找到一个名为junit.jar的文件。将这个jar文件加入你的CLASSPATH系统变量。（IDE的设置会有所不同，参看你所喜爱的IDE的配置指南）JUnit就安装完了。

四、运行

通过前面的介绍，我们对JUnit有了一个大概的轮廓。知道了它是干什么的。现在让我们动手改写上面的测试类testCar使其符合Junit的规范－－能在JUnit中运行。

//执行测试的类（JUnit版）

import junit.framework.*;

public class testCar extends TestCase

{

protected int expectedWheels;

protected Car myCar;

public testCar(String name)

{

super(name);

}

protected void setUp()

{

expectedWheels = 4;

myCar = new Car();

}

public static Test suite()

{

/** the type safe way */

/*

TestSuite suite= new TestSuite();

suite.addTest(

new testCar("Car.getWheels")

{

protected void runTest()

{

testGetWheels();

}

}

);

return suite;

*/

/** the dynamic way */

return new TestSuite(testCar.class);

}

public void testGetWheels()

{

assertEquals(expectedWheels, myCar.getWheels());

}

}

改版后的testCar已经面目全非。先让我们了解这些改动都是什么含义，再看如何执行这个测试。

1>import语句，引入JUnit的类。（没问题吧）

2>继续 TestCase 。可以暂时将一个TestCase看作是对某个类进行测试的方法的集合。具体介绍请参看JUnit资料

3>setUp()设定了进行初始化的任务。我们以后会看到setUp会有非凡的用处。

4>testGetWheeels()对预期的值和myCar.getWheels()返回的值进行比较，并打印比较的结果。assertEquals是junit.framework.Assert中所定义的方法，junit.framework.TestCase继续了junit.framework.Assert。

5>suite()是一个很非凡的静态方法。JUnit的TestRunner会调用suite方法来确定有多少个测试可以执行。上面的例子显示了两种方法：静态的方法是构造一个内部类，并利用构造函数给该测试命名(test name, 如 Car.getWheels)，其覆盖的runTest()方法，指明了该测试需要执行那些方法－－testGetWheels()。动态的方法是利用内省（reflection）来实现runTest()，找出需要执行那些测试。此时测试的名字即是测试方法（test method，如testGetWheels）的名字。JUnit会自动找出并调用该类的测试方法。

6>将TestSuite看作是包裹测试的一个容器。假如将测试比作叶子节点的话，TestSuite就是分支节点。实际上TestCase，TestSuite以及TestSuite组成了一个composite Pattern。JUnit的文档中有一篇专门讲解如何使用Pattern构造Junit框架。有爱好的朋友可以查看JUnit资料。

如何运行该测试呢？手工的方法是键入如下命令：

[Windows] D:\>java junit.textui.TestRunner testCar

[Unix] ％ java junit.textui.TestRunner testCar

别担心你要敲的字符量，以后在IDE中，只要点几下鼠标就成了。运行结果应该如下所示，表明执行了一个测试，并通过了测试：

.

Time: 0

OK (1 tests)

假如我们将Car.getWheels()中返回的的值修改为3，模拟出错的情形，则会得到如下结果：

.F

Time: 0.16

FAILURES!!!

Test Results:

Run: 1 Failures: 1 Errors: 0

There was 1 failure:

1) testCar.testGetWheels "expected:<3> but was:<4>"

注重：Time上的小点表示测试个数，假如测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。注重，在模拟出错的测试中，我们会得到具体的测试报告“expected:<3> but was:<4>”，这足以告诉我们问题发生在何处。下面就是你调试，测试，调试，测试...的过程，直至得到期望的结果。

五、Design by Contract（这句话我没法翻译）

Design by Contract本是Bertrand Meyer（Eiffel语言的创始人）开发的一种设计技术。我发现在JUnit中使用Design by Contract会带来意想不到的效果。Design by Contract的核心是断言（assersion）。断言是一个布尔语句，该语句不能为假，假如为假，则表明出现了一个bug。Design by Contract使用三种断言：前置条件（pre-conditions）、后置条件（post-conditions）和不变式（invariants）这里不打算具体讨论Design by Contract的细节，而是希望其在测试中能发挥其作用。

前置条件在执行测试之前可以用于判定是否答应进入测试，即进入测试的条件。如 expectedWheels > 0, myCar != null。后置条件用于在测试执行后判定测试的结果是否正确。如 expectedWheels==myCar.getWheels()。而不变式在判定交易(Transaction)的一致性（consistency）方面尤为有用。我希望JUnit可以将Design by Contract作为未来版本的一个增强。

六、Refactoring（这句话我依然没法翻译）

Refactoring本来与测试没有直接的联系，而是与软件熵有关，但既然我们说测试能解决软件熵问题，我们也就必须说出解决之道。（仅仅进行测试只能发现软件熵，Refactoring则可解决软件熵带来的问题。）软件熵引出了一个问题：是否需要重新设计整个软件的结构？理论上应该如此，但现实不答应我们这么做。这或者是由于时间的原因，或者是由于费用的原因。重新设计整个软件的结构会给我们带来短期的痛苦。而不停地给软件打补丁甚至是补丁的补丁则会给我们带来长期的痛苦。（不管怎样，我们总处于水深火热之中）

Refactoring是一个术语，用于描述一种技术，利用这种技术我们可以免于重构整个软件所带来的短期痛苦。当你refactor时，你并不改变程序的功能，而是改变程序内部的结构，使其更易理解和使用。如：该变一个方法的名字，将一个成员变量从一个类移到另一个类，将两个类似方法抽象到父类中。所作的每一个步都很小，然而1－2个小时的Refactoring工作可以使你的程序结构更适合目前的情况。Refactoring有一些规则：

1> 不要在加入新功能的同时refactor已有的代码。在这两者间要有一个清楚的界限。如天天早上1-2个小时的Refactoring，其余时间添加新的功能；

2> 在你开始Refactoring前，和Refactoring后都要保证测试能顺利通过，否则Refactoring没有任何意义；

3> 进行小的Refactoring，大的就不是Refactoring了。假如你打算重构整个软件，就没有必要Refactoring了。只有在添加新功能和调试bug时才又必要Refactoring。不要等到交付软件的最后关头才Refactoring。那样和打补丁的区别不大。Refactoring 用在回归测试中也能显示其威力。要明白，我不反对打补丁，但要记住打补丁是应该最后使用的必杀绝招。（打补丁也需要很高的技术，详情参看微软网站）

七、IDE对JUnit的支持

目前支持JUnit的Java IDE 包括

IDE