复旦大学：《面向对象分析和设计》课程资料_开源项目研讨报告_OOAD JUnit 研究总结.pdf_大学文库

目录 1. JUnit 研究总结 .............................................................................................................................3 1.1 JUnit 简介(李寻).................................................................................................................3 1.1.1 单元测试.................................................................................................................3 1.1.1.1 单元测试的好处..........................................................................................3 1.1.1.2 单元测试的针对对象..................................................................................3 1.1.1.3 单元测试工具和框架..................................................................................3 1.1.2 JUnit 优点和 JUnit 单元测试编写原则...................................................................3 1.1.3 JUnit 的特征 ............................................................................................................4 1.1.4 JUnit 框架与组成.....................................................................................................4 1.1.5 JUnit 的安装和配置.................................................................................................4 1.2 JUnit 架构分析(李寻).........................................................................................................5 1.2.1 接口分析.................................................................................................................5 1.2.2 JUnit 架构 ................................................................................................................7 1.3 JUnit 设计模式(夏勇杰) .....................................................................................................7 1.3.1 简介.........................................................................................................................7 1.3.2 什么是 JUnit 的目标呢？ ......................................................................................8 1.3.3 JUnit 的设计 ............................................................................................................8 1.3.3.1 由此开始－TestCase.................................................................................8 1.3.3.2 空白填充－run()....................................................................................10 1.3.3.3 结果报告－TestResult ...........................................................................11 1.3.3.4 不愚蠢的子类－再论 TestCase..............................................................14 1.3.3.5 不必关心一个或多个－TestSuit ...........................................................15 1.3.3.6 总结........................................................................................................17 1.3.4 结论.................................................................................................................19 1.4 JUnit 版本演化(朱帆).......................................................................................................20 1.5 JUnit 测试(张蔚婷)...........................................................................................................21 1.6 JUnit 集成应用(何文俊) ...................................................................................................24 1.6.1 应用综述...............................................................................................................24 1.6.2 JUnit 与 Eclipse 集成 .............................................................................................24 2. 个人贡献总结............................................................................................................................34 2.1 李寻 .................................................................................................................................34 2.1.1 小组组长...............................................................................................................34 2.1.2 JUnit 初步探索 ......................................................................................................35 2.1.3 JUnit 架构探索 ......................................................................................................35 2.2 夏勇杰..............................................................................................................................35 2.3 朱帆 .................................................................................................................................35 2.3.1 个人贡献................................................................................................................35 2.3.2 个人感想...............................................................................................................36 2.4 何文俊..............................................................................................................................36 2.5 张蔚婷..............................................................................................................................36

记录 Junit. jar文件所在目录名(例如C:\Junt3.81 Junit jar)。进入操作系统(以 Windows2000操作系统为准),按照次序点击“开始设置控制面板在控制面板选项中选择“系统”,点击“环境变量”,在“系统变量” 的“变量”列表框中选择“ CLASS-PATH”关键字(不区分大小写), 如果该关键字不存在则添加。双击“ CLASS-PATH”关键字添加字符串“C:\ Junit3.81 Junta. jar”(注意,如果已有别的字符串请在该字符串的字符结尾加上分号“;”), 这样确定修改后 Junit就可以在集成环境中应用了。对于IDE环境,对于需要用到的 JUnit的项目增加到ib中,其设置不同的IDE有不同的设置 12 JUnit架构分析 121接口分析 Test接口——运行测试和收集测试结果 Test接口使用了 Composite设计模式,是单独测试用例 ( Testcase),聚合测试模式( Testsuite)及测试扩展 ( TestDecorator)的共同接口。它的 public int countTestCases()方法,它来统计这次测试有多少个 Test case,另外一个方法就是 public void run Test Result), Test Result是实例接受测试结果,run方法执行本次测试。 Test Case抽象类——定义测试中固定方法 Test case是Test接口的抽象实现,(不能被实例化,只能被继承) 其构造函数 Test Case(string name根据输入的测试名称name创建个测试实例。由于每一个 Test case在创建时都要有一个名称, 若某测试失败了,便可识别出是哪个测试失败 TestCase类中包含的 setUp()、 tearDown(方法。 setUp(方法集中初始化测试所需的所有变量和实例,并且在依次调用测试类中的每个测试方法之前再次执行 setUp(方法。 tearDown()方法则是在每个测试方法之后,释放测试程序方法中引用的变量和实例。开发人员编写测试用例时,只需继承 TestCase,来完成run方法即可,然后 JUnit获得测试用例,执行它的run方法,把测试结果记录在 TestResult之中。 Assert静态类—系列断言方法的集合 Assert包含了一组静态的测试方法,用于期望值和实际值比对是否正确,即测试失败, Assert类就会抛出一个 Assertion Failed error

记录 Junit.jar 文件所在目录名（例如 C：＼Junit3.8.1\Junit.jar）。进入操作系统（以 Windows2000 操作系统为准），按照次序点击“开始设置控制面板”。在控制面板选项中选择“系统”，点击“环境变量”，在“系统变量” 的“变量”列表框中选择“CLASS‐PATH”关键字（不区分大小写），如果该关键字不存在则添加。双击“CLASS‐PATH”关键字添加字符串“C:＼Junit3.8.1\Junti.jar”(注意，如果已有别的字符串请在该字符串的字符结尾加上分号“；”)，这样确定修改后 Junit 就可以在集成环境中应用了。对于 IDE 环境，对于需要用到的 JUnit 的项目增加到 lib 中，其设置不同的 IDE 有不同的设置。 1.2 JUnit 架构分析 1.2.1 接口分析 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

异常,jυUnit测试框架将这种错误归入 Failes并加以记录,同时标志为未通过测试。如果该类方法中指定一个 String类型的传参则该参数将被做为 Assertion Failed error异常的标识信息,告诉测试人员改异常的详细信息。 JUnit提供了6大类31组断言方法,包括基础断言、数字断言、字符断言、布尔断言、对象断言。其中 assertEquals( Object expected, Object actua内部逻辑判断使用 equals()方法,这表明断言两个实例的内部哈希值是否相等时最好使用该方法对相应类实例的值进行比较。而 assertsame ( Object expected, Object actual)内部逻辑判断使用了Java运算符“==”,这表明该断言判断两个实例是否来自于同一个引用 ( Reference),最好使用该方法对不同类的实例的值进行比对。 asser equals( String message, String expected, String actual)该方法对两个字符串进行逻辑比对,如果不匹配则显示着两个字符串有差异的地方。 Comparison Failure类提供两个字符串的比对,不匹配则给出详细的差异字符。 TestSuite测试包类—多个测试的组合 Test Suite类负责组装多个 Test Cases。待测得类中可能包括了对被测类的多个测试,而 Testsuit负责收集这些测试,使我们可以在一个测试中,完成全部的对被测类的多个测试。 Testsuite类实现了Test接口,且可以包含其它的 Test suites。它可以处理加入Test时的所有抛出的异常。 TestSuite处理测试用例有6个规约(否则会被拒绝执行测试) A测试用例必须是公有类( Public) B测试用例必须继承与 Test case类 C测试用例的测试方法必须是公有的( Public) D测试用例的测试方法必须被声明为void E测试用例中测试方法的前置名词必须是test F测试用例中测试方法误任何传递参数 n Testresult结果类和其它类与接口 TestResult结果类集合了任意测试累加结果,通过 TestResult实例传递个每个测试的Run()方法。 TestResult在执行 Test Case是如果失败会异常抛出 Test listener接口是个事件监听规约,可供 TestRunner类使用。它通知 listener的对象相关事件,方法包括测试开始 startLes(Test test,测试结束 endTest( Testtest,错误,增加异常 add error(Test test. throwable t)和增加失败 add Failure(Test test, Assertion Failed Error t) Test Failure失败类是个“失败”状况的收集类,解释每次测试执行过程中出现的异常情况。其 toString方法返回“失败”状况的简要描述

异常，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 个规约（否则会被拒绝执行测试） A 测试用例必须是公有类（Public） B 测试用例必须继承与 TestCase 类 C 测试用例的测试方法必须是公有的（ Public ） D 测试用例的测试方法必须被声明为 Void E 测试用例中测试方法的前置名词必须是 test F 测试用例中测试方法误任何传递参数 n 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()方法返回“失败”状况的简要描述

132什么是 JUnit的目标呢? 首先,我们不得不回到开发的假定上去。如果缺少一个程序特性的自动测试 ( automated test),我们便假定其无法工作。这看起来要比主流的假定更加安全,主流的假定认为如果开发者向我们保证一个程序特性能够工作,那么现在和将来其都会永远工作。从这个观点来看,当开发者编写和调试代码时,它们的工作并没有完成,它们还要必须编写测试来演示程序能够工作。然而,每个人都太忙,他们要做的事情太多,他们没有充足的时间用于测试。我已经有太多的代码需要编写,要我如何再来编写测试代码?回答我,强硬的项目经理先生。因此,首要目标就是编写一个框架,在这个框架中开发者能够看到实际来编写测试的希望之光。该框架必须要使用常见的工具,从而学习起来不会有太多的新东西。其不能比完全编写一个新测试所必须的工作更多。必须排除重复性的工作。如果所有测试都这样去做的话,你将可以仅在一个调试器中编写表达式来完成。然而, 这对于测试而言尚不充分。告诉我你的程序现在能够工作,对我而言并没有什么帮助因为它并没有向我保证你的程序从我现在集成之后的每一分钟都将会工作,以及它并没有向我保证你的程序将依然能够工作五年,那时你已经离开了很长的时间于是,测试的第二个目标就是生成可持续保持其价值的测试。除原作者以外的其他人必须能够执行测试并解释其结果。应该能够将不同作者的测试结合起来并在一起运行,而不必担心相互冲突。最后,必须能够以现有的测试作为支点来生成新的测试。生成一个装置( setup)或夹具( fixture)是昂贵的,并且一个框架必须能够对夹具进行重用,以运行不同的测试。哦,还有别的吗? 133 JUnit的设计 JUnit的设计将以一种首次在 Patterns Generate Architectures(请参见" Patterns Generate Architectures", Kent Beck and Ralph Johnson, ECOOP94)中使用的风格来呈现。其思想是通过从零开始来应用模式,然后一个接一个,直至你获得系统架构的方式来讲解一个系统的设计。我们将提出需要解决的架构问题,总结用来解决问题的模式,然后展示如何将模式应用于 JUnit。 1331由此开始一 TestCase 首先我们必须构建一个对象来表达我们的基本概念, Testcase(测试案例)。开发者经常在头脑中存在着测试案例,但在实现它们的时候却采用了许多不同的方式一 1.打印语句 2.调试器表达式 3测试脚本

1.3.2 什么是 JUnit 的目标呢？首先，我们不得不回到开发的假定上去。如果缺少一个程序特性的自动测试（automated test），我们便假定其无法工作。这看起来要比主流的假定更加安全，主流的假定认为如果开发者向我们保证一个程序特性能够工作，那么现在和将来其都会永远工作。从这个观点来看，当开发者编写和调试代码时，它们的工作并没有完成，它们还要必须编写测试来演示程序能够工作。然而，每个人都太忙，他们要做的事情太多，他们没有充足的时间用于测试。我已经有太多的代码需要编写，要我如何再来编写测试代码？回答我，强硬的项目经理先生。因此，首要目标就是编写一个框架，在这个框架中开发者能够看到实际来编写测试的希望之光。该框架必须要使用常见的工具，从而学习起来不会有太多的新东西。其不能比完全编写一个新测试所必须的工作更多。必须排除重复性的工作。如果所有测试都这样去做的话，你将可以仅在一个调试器中编写表达式来完成。然而，这对于测试而言尚不充分。告诉我你的程序现在能够工作，对我而言并没有什么帮助，因为它并没有向我保证你的程序从我现在集成之后的每一分钟都将会工作，以及它并没有向我保证你的程序将依然能够工作五年，那时你已经离开了很长的时间。于是，测试的第二个目标就是生成可持续保持其价值的测试。除原作者以外的其他人必须能够执行测试并解释其结果。应该能够将不同作者的测试结合起来并在一起运行，而不必担心相互冲突。最后，必须能够以现有的测试作为支点来生成新的测试。生成一个装置（setup）或夹具（fixture）是昂贵的，并且一个框架必须能够对夹具进行重用，以运行不同的测试。哦，还有别的吗？ 1.3.3 JUnit 的设计 JUnit 的设计将以一种首次在 Patterns Generate Architectures（请参见"Patterns Generate Architectures", Kent Beck and Ralph Johnson, ECOOP 94）中使用的风格来呈现。其思想是通过从零开始来应用模式，然后一个接一个，直至你获得系统架构的方式来讲解一个系统的设计。我们将提出需要解决的架构问题，总结用来解决问题的模式，然后展示如何将模式应用于 JUnit。 1.3.3.1 由此开始－TestCase 首先我们必须构建一个对象来表达我们的基本概念，TestCase（测试案例）。开发者经常在头脑中存在着测试案例，但在实现它们的时候却采用了许多不同的方式－ 1. 打印语句 2. 调试器表达式 3. 测试脚本

如果我们想要轻松地操纵测试,就必须将它们构建成对象。这将会获取到一个仅仅是隐藏在开发者头脑中的测试,并使之具体化,其支持我们创建测试的目标,即能够持续地保持它们的价值。同时,对象的开发者比较习惯于使用对象来进行开发,因此将测试构建成对象的决定支持我们的目标一使测试的编写更加吸引人(或至少是不太华丽 Command(命令)模式(请参见 Gamma,E,etal. Design Patterns: Elements of reusable Object-Oriented Software, Addison- Wesley, Reading,MA,1995)则能够比较好地满足我们的需求。摘引其意图( intent),“将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;对请求进行排队或记录请求日志…” Command告诉我们可以为一个操作生成一个对象并给出它的一个“ execute(执行)”方法。以下代码定义了 TestCase类: public abstract class TestCase implements Test 因为我们期望可以通过继承来对该类进行重用,我们将其声明为“ public abstract 暂时忽略其实现接口Test的事实。鉴于当前设计的需要,你可以将 Test case看作是个孤立的类。每一个 Testcase在创建时都要有一个名称,因此若一个测试失败了,你便可识别出失败的是哪个测试。 public abstract class TestCase implements Test i private final String fName public TestCase(String name) public abstract void run( 为了阐述JUnt的演变过程,我们将使用图( diagram)来展示构架的快照( snapshot) 我们使用的标记很简单。其使用包含相关模式的尖方框来标注类。当类在模式中的角色(role)显而易见时,则仅显示模式的名称。如果角色并不清晰,则在尖方框中增加与该类相关的参与者的名称。该标记可使图的混乱度降到最小限度,并首次见诸于 Applying Design Patterns in Java (H L Gamma, E, Applying Design Patterns in Java, in Java gems, SIGS Reference Library,1997)。图1展示了这种应用于 Testcase中的标记。由于我们是在处理一个单独的类并且没有不明确的地方,因此仅显示模式的名称。 Testcase Command runo

如果我们想要轻松地操纵测试，就必须将它们构建成对象。这将会获取到一个仅仅是隐藏在开发者头脑中的测试，并使之具体化，其支持我们创建测试的目标，即能够持续地保持它们的价值。同时，对象的开发者比较习惯于使用对象来进行开发，因此将测试构建成对象的决定支持我们的目标－使测试的编写更加吸引人（或至少是不太华丽）。 Command（命令）模式（请参见 Gamma, E., et al. Design Patterns: Elements of Reusable Object‐Oriented Software, Addison‐Wesley, Reading, MA, 1995）则能够比较好地满足我们的需求。摘引其意图（intent），“将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求进行排队或记录请求日志...”Command 告诉我们可以为一个操作生成一个对象并给出它的一个“execute（执行）”方法。以下代码定义了 TestCase 类： public abstract class TestCase implements Test { … } 因为我们期望可以通过继承来对该类进行重用，我们将其声明为“public abstract”。暂时忽略其实现接口 Test 的事实。鉴于当前设计的需要，你可以将 TestCase 看作是一个孤立的类。每一个 TestCase 在创建时都要有一个名称，因此若一个测试失败了，你便可识别出失败的是哪个测试。 public abstract class TestCase implements Test { private final String fName; public TestCase(String name) { fName= name; } public abstract void run(); … } 为了阐述 JUnit 的演变过程，我们将使用图（diagram）来展示构架的快照（snapshot）。我们使用的标记很简单。其使用包含相关模式的尖方框来标注类。当类在模式中的角色（role）显而易见时，则仅显示模式的名称。如果角色并不清晰，则在尖方框中增加与该类相关的参与者的名称。该标记可使图的混乱度降到最小限度，并首次见诸于 Applying Design Patterns in Java（请参见 Gamma, E., Applying Design Patterns in Java, in Java Gems, SIGS Reference Library, 1997）。图 1 展示了这种应用于 TestCase 中的标记。由于我们是在处理一个单独的类并且没有不明确的地方，因此仅显示模式的名称