与JUnit干杯 ---- JUnit框架的架构原理以及应用

类别:Java 点击:0 评论:0 推荐:

DRINKING WITH JUNIT


作者: 乐晨光 [[email protected]]  (欢迎自由转载本文,但请注明作者及出处)

 


安全合理而富有可扩展性与可读性的测试代码进入了对象中,它就象一棵大数那样支撑起了整个工程。

1. PURPOSE

u       理解系统测试与单元测试的目的与方式
u       考察Junit测试框架的客户层应用;并架构一个待测试的系统案例。
u       考察分析Junit的框架架构原理。

2. THE TESTING

2.1 软件熵(software entropy)的概念:一个程序从设计很好的状态开始,随着新的功能不断地加入,程序逐渐地失去了原有的结构,最终变成了一团乱麻。(其实该处的“很好的状态”得加个?)
2.2
测试的目的:简单而极具活力,写出高质量的软件并解决软件熵这一问题。
2.3 测试的分类:白箱测试、黑箱测试;或,单元测试、集成测试、功能测试等有多种分类方法。

   白箱测试 -> 指知道被测试的软件如何(how)完成功能测试和完成什么样的功能(what)的条件下所作的测试。(一般由开发人员完成)
                          单元测试应属于白箱测试。
  黑箱测试 -> 在知道被测试的软件完成什么样(what)的功能的条件下所作的测试。(一般由测试人员完成)
  单元测试 -> 目的为验证一个或若干个类是否按所设计那样正常工作与表现。
  集成测试 -> 验证所有的类是否可以相互配合,协同完成特定的任务。(复杂的信号与事件通讯与状态机密集大的运作测试)

<<<< Junit应用于单元测试 >>>>

2.4 测试作为一项持续的过程,它贯穿与开发的整个过程中,单元测试尤适合迭代增量式(iteraton and incremental)的开发过程。
最简单的说:测试就是比较预期结果是否与实际执行结果一致。 







3.ARCHITECTURE OF JUNIT 3.1 Goal of JUnit

u       创建一个通用的测试框架,将测试代码封装入对象中,从而使开发者乐于同步设计并配置自己的单元测试。

u       让测试代码具备保值性,使(以往是个人化的)测试代码的进行方式标准化,可为多人共同浏览、维护。

u       将测试代码从系统代码中剥离开,二者可同步发展。


3.2 JUnit的框架成员逻辑分析

1.         被测试的对象(类,多个类,子系统)(Object be Tested

2.         对测试目标进行测试的方法与过程集合,可将其称为测试容器。(TestCase

3.         测试事务的集合,可容纳多个测试容器(TestCase),将其称作测试事务包。(TestSuite

4.         测试结果的描述与记录。(TestResult

5.         每一个测试方法所发生的与预期不一致状况的描述,称其测试失败元素。(TestFailure

6.         JUnit Framework中的出错异常。(AssertionFailedError


3.3 JUnit框架功能以及原理描述(junit.framework.*


u       Test接口与TestCase、TestSuite形成了Composite结构,Run(TestResult) 则是Composite Methode。Test为Component,派生出的TestCase为Leaf,是测试的执行元素;TestSuite为Composite,其可通过addTest(Test)来容纳Test组合(TestCase or TestSuite)形成测试包。


u       TestCase可在框架中视为测试单元的运行实体。用户可以通过它派生自定义的测试过程与方式(单元),利用Command Pattern与Composite Pattern使其形成可组合装配的可扩展的测试批处理。TestCase本身的运作操作为run(TestResult),其中分别执行setUp(),runTest(),tearDown()来架构测试过程。Template Mothod Pattern使用户无须了解执行框架的过程细节,而只需重定义特性化的测试预处理,测试单元过程,以及测试完毕测试三个Template Mothod就能使测试正确工作。




 




 


u       用户层可通过Java的匿名内部类(Anonymous Inner Classes)来集成化重载runTest()形成特性测试类,同时JUnit3.0版本以后则支持利用Java的Class属性来动态框架后台生成这些特性测试单元类,而用户只需在TestCase派生类的testXXX()即可,在suite中使用return new TestSuite(MyTestCase.class);后该TestSuite就包含了所有testXXX为测试过程的TestCase类对象集合。


u       Assert类包含了assertEqual(..),assertSame(..),assertTrue(.)等静态工具方法(static tools methods),为使用户对系统所了解的类型尽可能少,JUnit框架将Assert作为了TestCase的超类,TestCase同时继承了Assert的实现与Test接口(class Adepter pattern)。用户可在TestCase中直接调用这些assertXXX(..)等静态工具方法。


u       TestResult描述了整个测试执行过程的测试结果,JUnit框架将其作为参数传递与Test的run(.)间,当测试任务执行完毕后,TestResult内则包含了所有TestCase的测试结果。框架默认的TestResult为TextTestResult,用户也可以自定义其TestResult的回显格式,譬如HTMLTestResult。


TestFailure描述了测试过程中的错误信息,TestResult通过Vector容纳了测试过程中生成的TestFailure,将其作为测试结果参数依据。

4. CLIIENT LAYER OF JUNIT


Import junit.framework.*;

用户通过派生TestCase来自定义特性Test案例,在TestCase中可包含系统待测试类型的对象,同时在其内定义若干testXXX()做test method。

覆盖setUp()来为每一次测试前做系统状态预处理,在tearDown()中清理。


安排测试过程有两种常用的方法:

1.       通过创建内部类来集成化覆盖runTest()方法,里边填充testXXX()

2.       通过class作为TestSuite的构造参数来动态创建测试包。( 其中所有的testXXX()均分别作为了一个新的特性TestCase的测试主方法[runTest{testXXX();}中] )


注意每一次测试(runTest)都应该相互是相互独立的,被测试对象不应该有上下文关系。(这是由于TestSuite容纳Test的vector的无序性)

 


5. TEST ZERG-COMMAND-SYSTEM WITH JUNIT


作为JUnit的测试案例,我架构了一个测试案例。


JUnit作为一个单元测试框架,开发者应该明确创设什么样的测试,如何测试,测试系统的什么部分以及方式,或是测试系统的整合表现。


该系统描述的是一个外星种族Zerg之星球作战指令系统。


 


ZCommand系统是一个Command & Composite架构,ZcommandGroup容纳若干命令(可视为批处理),ZconcreteCommand(ZCFire/ZCLoadAmmo/ZCAction)描述了3种具体命令类别(包含具体特性参数)


Zcommand的execute是一个composite method,可处理组合命令的批量执行。


架构这个系统的同时,要利用JUnit框架来测试该组合的性质。考察该命令系统,算法复杂区域表现在组合集成的过程里,以及执行组合执行的遍历过程。


public class TestCommandModel extends TestCase {}1. testCommandGroupCount() 测试一份组合命令所包含的子命令数目。
2. testCommandString() 测试组合命令执行的遍历回显过程。
3.  testCommandGroupUpdate() 测试add, remove, clear等组合操作的正确性。
(详见junitzerg.test.TestCommandModel.java)

ZfighterMachine描述了一架作战指挥终端。ZergCommandCentre描述了Zerg作战指挥处理中心,ZfighterMachine将作战人员生成的Zcommand(component)传递给ZcommandCentre(remote object) 来处理该指令并等待一份执行结果。


ZcommandCentre维护了个系统的工作状态,不同的作战指令(Zcommand)在不同的系统工作状态下有着不同的处理方式,这一套系统规则形成了一个复杂的逻辑区(complex logic zone)


该逻辑区的信号传入与结果反馈正应为单元测试应实行的内容。故价构了TestMachine来测试ZfighterMachine与ZergCommandCentre的工作状态。


public class TestMachine extends TestCase {}

1. testSimpleCommand() 测试简单指令元素在不同系统状态下的执行结果。

2. testExtremeCondition() 测试ZergCommandCentre在极端环境下(能源不足、弹药不足、通讯干扰)的工作情况。

3. testAllCondition() 则测试所有种类的Command在所有condition下的执行结果与工作状况。

(备注:详见junitzerg.test.TestMachine.java,TestAll则批处理执行所有的测试)


6. SUMMARY & CONCLUSION


1.设计一个应当失败的测试。

2.勿用TestCase的Constructor初始化Fixtures,用setUp/tearDown。

3. 避免编写有副作用的TestCase。

4.   确保测试与时间无关,莫依赖使用过期的数据进行测试。

5.   尽可能利用JUnit提供的assertXXX/fail方法以及异常处理,使测试代码统一化。
6.   如果编写的软件面向国际市场,则编写测试时要考虑国际化的因素。
7.  无意间发现JUnit的作者包括Erich Gamma。

7. EXTENSION

1. 测试的关键是洞悉系统的复杂区域与不稳定区域,抽取其做测试。
2. 管理测试模块与系统本身模块,使其同步发展。
3. JUnit仅为一份单元测试的应用框架,集成测试的框架又会是何其。
4. 考察总结开发与测试并同的工作模式,以加快工程开发的运行效率。

                                                                                          

                                                                                             乐晨光 2002-2-26

本文地址:http://com.8s8s.com/it/it18374.htm