用JUnit框架实现Java单元测试

http://tech.it168.com/j/2007-08-27/200708271737659.shtml

单元测试是整个测试流程中最基础的部分，它们要求程序员尽可能早地发现问题，并给予控制，这是其一。另外，如果集成测试出现问题，它们可以帮助诊断。这样就为在软件开发流程中建立高效的事件反应机制打下了坚实基础。

　JUnit就是为Java程序开发者实现单元测试提供一种框架，使得Java单元测试更规范有效，并且更有利于测试的集成。

　JUnit的内部结构
　JUnit的软件结构

　JUnit 共有七个包，核心的包就是junit.framework 和junit.runner。Framework包负责整个测试对象的构架，Runner负责测试驱动。

　JUnit的类结构

　JUnit有四个重要的类：TestSuite、TestCase、TestResult、TestRunner。前三个类属于Framework包，后一个类在不同的环境下是不同的。这里使用的是文本测试环境，所以用的是 junit.textui.TestRunner。各个类的职责如下：

　　1.TestResult，负责收集TestCase所执行的结果，它将结果分为两类，客户可预测的Failure和没有预测的Error。同时负责将测试结果转发到TestListener（该接口由TestRunner继承）处理；
　　2.TestRunner，客户对象调用的起点，负责对整个测试流程的跟踪。能够显示返回的测试结果，并且报告测试的进度。
　　3.TestSuite， 负责包装和运行所有的TestCase。
　　4.TestCase， 客户测试类所要继承的类，负责测试时对客户类进行初始化，以及测试方法调用。

　另外还有两个重要的接口：Test和TestListener。
　　1.Test, 包含两个方法：run() 和countTestCases()，它是对测试动作特征的提取。
　　2.TestListener， 包含四个方法：addError()、addFailure()、startTest()和endTest()，它是对测试结果的处理以及测试驱动过程的动作特征的提取。

　下面给出的两个类图（篇幅有限，只显示主要部分）很好地阐明了类之间的关系，以及junit的设计目标（如图1）。测试案例的类采用Composite模式。这样，客户的测试对象就转变成一个“部分—整体”的层次结构。客户代码仅需要继承类TestCase，就可以轻松的与已有的其他对象组合使用，从而使得单元测试的集成更加方便。

图1 测试结构图

    图2是测试跟踪类图。图2左边TestSuite包含了测试对象集合，右边包含了测试结果集。具体如何处理结果，以及包含哪些测试对象，并没有立即得出结论，而是尽量地延迟到具体实现的时候。例如，实现接口TestListener的JUnit中就含有：junit.awtui.TestRunner、junit.swingui. TestRunner、junit.ui.TestRunner等，甚至客户用自己的类实现TestListener，从而达到多样化的目的。

图2 测试跟踪图

    从以上两个类图，可以了解JUnit对单元测试的基本思路，这个框架的核心就是结果集和案例集。

 

JUnit的实现流程

　典型的使用JUnit的方法就是继承TestCase类，然后重载它的一些重要方法：setUp()、teardown()、runTest()(这些都是可选的)，最后将这些客户对象组装到一个TestSuite对象中，交由 junit.textui.TestRunner.run (案例集) 驱动。下面分析案例集是如何运转的。

　图3基本上阐述JUnit的测试流程架构。我们将从不同的角度来详细分析这个图。

图3 测试序列图

 

首先，从对象的创建上来分析。客户类负责创建Suite和aTestRunner。注意，类TestRunner含有一个静态函数Run(Test),它自创建本身，然后调用doRun()。客户类调用的一般是该函数，其代码如下：

   
   

    
    static
    
     
    
    public
    
     
    
    void
    
     run(Test suite){
　　　TestRunner aTestRunner
    
    =
    
     
    
    new
    
     TestRunner();
    
    //
    
    新建测试驱动
    
    

    
    　　　aTestRunner.doRun(suite, 
    
    false
    
    );
    
    //
    
    用测试驱动运行测试集
    
    

    
    }
   
   

    Suite对象负责创建众多的测试案例，并将它们包容到本身。客户测试案例继承TestCase类，它将类,而不是对象传给Suite对象。Suite对象负责解析这些类、提取构造函数和待测试方法。以待测试方法为单位构造测试案例，测试案例的fName就是待测试方法名。测试结果集由aTestRunner创建。这似乎同先前阐述的类图有些矛盾，那里阐述了一个测试集可以包含很多个不同的测试驱动，似乎先创建结果集比较理想。显然，这里对测试结果的处理只采用了一种方式，所以这样做同样可行。

　其次，从测试动作的执行上来分析，测试真正是从suite.run(result) 开始的。其代码如下：

   
   

    
    public
    
     
    
    void
    
     run(TestResult result){
　　
    
    //
    
    从案例集中获得所有测试案例，分别执行
    
    

    
    　　 
    
    for
    
     (Enumeration e
    
    =
    
     tests(); e.hasMoreElements(); )
　　 {
　　　
    
    if
    
     (result.shouldStop() )
　　　
    
    break
    
    ;
　　　Test test
    
    =
    
     (Test)e.nextElement();
　　　runTest(test, result);
　　 }
}
   
   

    一旦测试案例开始执行，首先使用一个回调策略将自身交由Result。这样做的每一步测试，测试驱动aTest Runner都可以跟踪处理。这无形中建立了一个庞大的监视系统，随时都可以对所发生的事件给予不同等级的关注。

　我们分析一下涉及到的动作行为的设计模式：

　1. Template Method （模板方法）类行为模式，它的实质就是首先建立方法的骨架，而尽可能地将方法的具体实现向后推移。TestCase.runBare()就采用了这种模式，客户类均可以重载它的三个方法，这样使得测试的可伸缩性得到提高。

   
   

    
    public
    
     
    
    void
    
     runBare() throws Throwable{
　　 setUp();
　　 
    
    try
    
     {runTest();}
　　 
    
    finally
    
     {tearDown();}
}
   
   

    2. Command （命令）对象行为模式，其实质就是将动作封装为一个对象，而不关心动作的接收者。这样动作的接收者可以一直到动作具体执行时才需确定。接口Test就是一个Command集，使得不同类的不同测试方法可以通过同一种接口Test构造其框架结构。这样对测试的集成带来了很多方便。

 

JUnit的Exception的抛出机制

　JUnit的异常层次分为三层：1.Failure,客户预知的测试失败，可以被Assert方法检测到；2. Error，客户测试的意外造成的；3.Systemerror, JUnit的线程死亡级异常，这种情况一般很少发生。JUnit的这三种异常在TestResult类的RunProtected()方法得到很好体现。这里用Protectable接口封装了Test的执行方法，其实p.protect执行的就是test.runBare()。

   
   

    
    public
    
     
    
    void
    
     runProtected(final Test test, Protectable p){
　　 
    
    try
    
     {p.protect();}
　　 
    
    catch
    
     (AssertionFailedError e)　
　　 {addFailure(test, e);}
　　 
    
    catch
    
     (ThreadDeath e)
　　 {rethrow e;}
　　 
    
    catch
    
     (Throwable e)
　　 {addError(test, e);}
}
   
   

    代码首先检查是否是Assertion FailedError，然后判断是否是严重的ThreadDeath。这种异常必须Rethrow，才能保证线程真正的死亡，如果不是，说明它是一种意外。

　前两种异常均保存在测试结果集中，等到整个测试完成，依次打印出来供客户参考。

实施JUnit的几点建议

　从以上的分析中，可以了解JUnit的结构和流程，但是在实际应用JUnit时，有几点建议还需要说明，如下：

　1. 客户类可以重载runTest(),它的缺省实现是调用方法名为fName的测试方法。如果客户不是使用TestSuite加载TestCase,就尤其需要对其重载，当然这种方式并不赞成使用，不利于集成。另外，setUp()和tearDown()的功能似乎与构造函数雷同，但如果测试案例之间具有类继承关系，采用构造函数初始化一些参数就会造成数据的混乱，不利于判定测试结果的有效性。

　2. 待测试函数的调用顺序是不确定的，采用的数据结构是Vector()。如果需要有顺序关系，可以将它们组合到一起，然后用同一个测试方法。

　3. 为了使测试结果清晰明了，程序中最好不要有打印输出，要么程序的打印输出与JUnit测试的打印输出不要用同一个数据源System.out。其实这是两种测试习惯，直接打印输出是较传统的，从测试动机上考虑它也是较随意的，并且结果需要人工观察。如果直接打印输出较多的话，观察者可能无法获得满意的结果。

　　此外，如何扩展这个测试框架呢？ junit.extensions包给出了几点提示。我们可以使用junit.extensions. ActiveTest在不同的线程中运行一个测试实例。 对于要对测试案例添加新的功能可以采用Decorator模式，可以参考junit.extensions.TestDecorator以及它的子类junit.extensions.TestSetup、junit.extensions.RepeatedTest。这些仅仅提供了一些拓宽的思路，涉及到具体测试目标，还需进一步地挖掘。

 

＝==========

http://tech.it168.com/j/2007-08-29/200708291342456.shtml

1、相关概念

Ø JUnit：是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。它是用于单元测试框架体系xUnit的一个实例（用于java语言）。主要用于白盒测试，回归测试。
Ø 白盒测试：把测试对象看作一个打开的盒子，程序内部的逻辑结构和其他信息对测试人
员是公开的。
Ø 回归测试：软件或环境的修复或更正后的再测试，自动测试工具对这类测试尤其有用。
Ø 单元测试：最小粒度的测试，以测试某个功能或代码块。一般由程序员来做，因为它需要知道内部程序设计和编码的细节。

2、 单元测试

2.1、单元测试的好处
Ø 提高开发速度，测试是以自动化方式执行的，提升了测试代码的执行效率。
Ø 提高软件代码质量，它使用小版本发布至集成，便于实现人员除错。同时引入重构概念，让代码更干净和富有弹性。
Ø 提升系统的可信赖度，它是回归测试的一种。支持修复或更正后的“再测试”，可确保代码的正确性。

2.2、单元测试的针对对象
Ø 面向过程的软件开发针对过程。
Ø 面向对象的软件开发针对对象。
Ø 可以做类测试，功能测试，接口测试（最常用于测试类中的方法）。

2.3、单元测试工具和框架
目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。
单元测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。

3、Junit入门简介

3.1、JUnit的好处和JUnit测试编写原则
使用JUnit的好处：
Ø 可以使测试代码与产品代码分开。
Ø 针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试。
Ø 易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发。
Ø JUnit是公开源代码的，可以进行二次开发。
Ø 可以方便地对JUnit进行扩展。

JUnit测试编写原则：
Ø 简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写。
Ø 使测试单元保持持久性。
Ø 可以利用既有的测试来编写相关的测试。

3.2、JUnit的特征
Ø 使用断言方法判断期望值和实际值差异，返回Boolean值。
Ø 测试驱动设备使用共同的初始化变量或者实例。
Ø 测试包结构便于组织和集成运行。
Ø 支持图型交互模式和文本交互模式。

3.3 JUnit框架组成
Ø 对测试目标进行测试的方法与过程集合，可称为测试用例(TestCase)。
Ø 测试用例的集合，可容纳多个测试用例(TestCase)，将其称作测试包(TestSuite)。
Ø 测试结果的描述与记录。(TestResult) 。
Ø 测试过程中的事件监听者(TestListener)。
Ø 每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素(TestFailure)
Ø JUnit Framework中的出错异常（AssertionFailedError）。

    JUnit框架是一个典型的Composite模式：TestSuite可以容纳任何派生自Test的对象；当调用TestSuite对象的run()方法是，会遍历自己容纳的对象，逐个调用它们的run()方法。3.5 JUnit中常用的接口和类

Ø Test接口：运行测试和收集测试结果

    Test接口使用了Composite设计模式，是单独测试用例（TestCase），聚合测试模式（TestSuite）及测试扩展（TestDecorator）的共同接口。 它的public int countTestCases（）方法，用来统计测试时有多少个TestCase。另外一个方法就是public void　run（ TestResult ），TestResult是实例接受测试结果， run方法执行本次测试。

Ø TestCase抽象类：定义测试中固定方法

    TestCase是Test接口的抽象实现，（不能被实例化，只能被继承）其构造函数TestCase(string name)根据输入的测试名称name创建一个测试实例。由于每一个TestCase在创建时都要有一个名称，若测试失败了，便可识别出是哪个测试失败。
TestCase类中包含的setUp()、tearDown()方法。

    setUp()方法集中初始化测试所需的所有变量和实例，并且在依次调用测试类中的每个测试方法之前再次执行setUp()方法。
tearDown()方法则是在每个测试方法之后，释放测试程序方法中引用的变量和实例。

    开发人员编写测试用例时，只需继承TestCase，来完成run方法即可，然后JUnit获得测试用例，执行它的run方法，把测试结果记录在TestResult之中。

Ø Assert静态类：一系列断言方法的集合

    Assert包含了一组静态的测试方法，用于期望值和实际值比对是否正确，即测试失败，Assert类就会抛出一AssertionFailedError异常，JUnit测试框架将这种错误归入Failes并加以记录，同时标志为未通过测试。如果该类方法中指定一个String类型的传参则该参数将被做为AssertionFailedError异常的标识信息，告诉测试人员改异常的详细信息。

    JUnit 提供了6大类31组断言方法，包括基础断言、数字断言、字符断言、布尔断言、对象断言。其中assertEquals（Object expcted,Object actual)内部逻辑判断使用equals()方法，这表明断言两个实例的内部哈希值是否相等时，最好使用该方法对相应类实例的值进行比较。

    而assertSame（Object expected,Object actual）内部逻辑判断使用了Java运算符“==”，这表明该断言判断两个实例是否来自于同一个引用（Reference），最好使用该方法对不同类的实例的值进行比对。
asserEquals(String message,String expected,String actual)该方法对两个字符串进行逻辑比对，如果不匹配则显示着两个字符串有差异的地方。

    ComparisonFailure类提供两个字符串的比对，不匹配则给出详细的差异字符。

Ø TestSuite测试包类??多个测试的组合

    TestSuite类负责组装多个Test Cases。待测得类中可能包括了对被测类的多个测试，而TestSuit负责收集这些测试，使我们可以在一个测试中，完成全部的对被测类的多个测试。TestSuite类实现了Test接口，且可以包含其它的TestSuites。它可以处理加入Test时的所有抛出的异常。

TestSuite处理测试用例有6个规约（否则会被拒绝执行测试）
² 测试用例必须是公有类（Public）
² 用例必须继承与TestCase类
² 测试用例的测试方法必须是公有的（ Public ）
² 测试用例的测试方法必须被声明为Void
² 测试用例中测试方法的前置名词必须是test
² 测试用例中测试方法误任何传递参数

Ø TestResult结果类和其它类与接口
    TestResult结果类集合了任意测试累加结果，通过TestResult实例传递个每个测试的Run（）方法。TestResult在执行TestCase是如果失败会异常抛出。 

    TestListener接口是个事件监听规约，可供TestRunner类使用。它通知listener的对象相关事件，方法包括测试开始startTest(Test test)，测试结束endTest(Test test),错误，增加异常addError(Test test,Throwable t)和增加失败addFailure(Test test,AssertionFailedError t)。

    TestFailure失败类是个“失败”状况的收集类，解释每次测试执行过程中出现的异常情况。其toString()方法返回“失败”状况的简要描述

4、Eclipse中JUnit的使用

    测试对于保证软件开发质量有着非常重要的作用，单元测试更是必不可少，JUnit是一个非常强大的单元测试包，可以对一个/多个类的单个/多个方法测试，还可以将不同的TestCase组合成TestSuit，使测试任务自动化。
Eclipse同样集成了JUnit，可以非常方便地编写TestCase。Eclipse自带了一个JUnit的插件，不用安装就可以在你的项目中开始测试相关的类，并且可以调试你的测试用例和被测试类。

4.1、Eclipse中JUint使用步骤

以下步骤环境为Eclipse SDK 3.2.2及JUnit3.8.1
Ø 新建一个测试用例或选择已有的所想测试的JAVA文件，点击“File->New->…”菜单项或右击文件，在弹出的“New”对话框中选择“JUnit Test Case”，就进入“New JUnit Test Case”对话框

Ø 在“New JUnit TestCase”对话框填写相应的栏目，主要有Name（测试用例名），SuperClass（若JUnit的版本是3.8.1，则测试的超类一般默认为junit.framework.TestCase； 若JUnit版本是JUnit 4.4，则默认超类为java.lang.Object。），Class Under Test（被测试的类），Source Folder（测试用例保存的目录），Package（测试用例包名），及是否自动生成main，setUp，tearDown方法。在此一般填写NAME及选上复选上setUpt和teardown即可。

Ø 点击“Next>”按钮，则进入Test Methods，在此你可以直接勾选你想测试的被测试类的方法，Eclipse将自动生成与被选方法相应的测试方法，点击“Fishish”按钮后一个测试用例就创建好了。

Ø 编写完成测试用例后，点击“Run”按钮就可以看到运行结果了。

    补充：要使用JUnit，您必须首先将JUnit JAR保存在项目的Build路径上并创建一个测试类。将JUnit保存在项目的Build路径上的步骤为：

    右击项目—>选择菜单底部的Properties选择Java Build Path—>选择Libraries—>点击Add Variable按钮—>查看已有的列表中有无JUnit文件，若没有，则点击Configure Variable—>New按钮，输入JUNIT_LIB作为变量名称，编辑该变量并指向解压后的JUnit目录中的一个名为JUnit.jar的文件—>然后在选择刚才添加的jar文件依次点击OK即可。

4.2、Eclipse中JUnit应用示例

    下面我们作一个在Eclipse中利用JUnit对HelloWorld的测试 测试方法：
Ø HelloWorld.sayHello()是否执行正常，并且结果也符合要求
Ø HelloWorld.add()方法是否与我们预期一样执行

    下一步，我们准备对这两个方法进行测试，确保功能正常。选中HelloWorld.java，右键点击，选择New->JUnit Test Case：

    进入下面这个页面，在此诸多栏目已经填好，即是这个需要测试的文件的相关信息，若是想在测试完之后即删除测试文件，也可更改路径。（本机在Eclipse已有的JUnit3.8.1的基础上又添加了一个新版本JUnit4.4）

    点击Next进入Test Methods，在此选择所要测试的方法sayHello及add。

    点击Finish，最后编写完成测试用例代码如下：

    直接运行Run->Run As->JUnit Test，就可以看到JUnit测试结果：

    绿色表示测试通过，只要有1个测试未通过，就会显示红色并列出未通过测试的方法。

5、后记

    从上面的来看，JUnit的使用并不很难，但关键就是最后一步完成测试码，即编写TestCase。要编写一个好的TestCase却并非易事。一个不好的TestCase往往是既浪费了时间，也起不了实际的作用。相反，一个好的TestCase，不仅可以很好的指出代码中存在的问题，而且也可以作为代码更准确的文档，同时还在持续集成的过程中起非常重要的作用。我们在作测试写TestCase时需要注意的几点：

Ø 测试的独立性：一次只测试一个对象，方便定位出错的位置。这有两层意思：一个TestCase，只测试一个对象；一个TestMethod，只测试这个对象中的一个方法。

Ø 给测试方法一个合适的名字。 一般取名为原来的方法名后加一个Test。

Ø 在assert函数中给出失败的原因，如：assertTrue( “… should be true”, ……)，方便查错。在这个例子中，如果无法通过assertTrue，那么给出的消息将被显示。在junit中每个assert函数都有第一个参数是出错时显示消息的函数原型。

Ø 测试所有可能引起失败的地方，如：一个类中频繁改动的函数。对于那些仅仅只含有getter/setter的类，如果是由IDE（如Eclipse）产生的，则可不测；如果是人工写，那么最好测试一下。

Ø 在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如针对与测试方法A和B，在setUp和tearDown中的代码应该是A和B都需要的代码。

Ø 测试代码的组织：相同的包，不同的目录。这样，测试代码可以访问被测试类的protected变量/方法，方便测试代码的编写。放在不同的目录，则方便了测试代码的管理以及代码的打包和发布。