JUnit软件测试

蒋刚毅Junit测试基础JUnit概述JUnit在Java测试工具中的地位是Java语言事实上的标准单元测试库。真正的优势来自于JUnit所采用的思想和技术，而不是框架本身。推动了单元测试、测试先行的编程和测试驱动的开发。Junit衍生了许多xUnit工具，将单元测试的优势应用于各种语言。影响了各种平台和语言上的程序员的测试工作。作者:ErichGamma和KentBeckJUnit4的新特性:Java5中的annotationXP、TDD开发方法的四个关键价值沟通(Communication)为人们提供一个自由讨论项目的地方、氛围、方式。简单(Simplicity)选择最简单的设计、技术、算法和技巧使客户满意。反馈(Feedback)任何代码的修改都能快速的得到有价值的反馈。勇气(Courage)如果代码有“坏味道”，将其重构。测试是勇气的关键。JUnit的相关软件Eclipse:3.2以上支持Junit4Ant：基于Java的开源构建工具，您可以在上得到最新的版本和丰富的文档。必需1.7或者以上版本），否则不能很好的支持JUnit4。Junit4：环境搭建首先为我们的体验新建一个Java工程——coolJUnit。现在需要做的是，打开项目coolJUnit的属性页-选择“JavaBuildPath”子选项-点选“AddLibrary…”按钮-在弹出的“AddLibrary”对话框中选择JUnit（图1），并在下一页中选择版本4.1后点击“Finish”按钮。这样便把JUnit引入到当前项目库中了。JUnit环境搭建测试代码的组织1.测试类的命名定义规范测试类的命名规则是：Test+被测试的业务、Test+被测试的接口、Test+被测试的类。类的名字必须由大写字母开头而单词中的其他字母均为小写；如果类名称由多个单词组成，则每个单词的首字母均应为大写，如TestMobileBind。如果类名称中包含单词缩写，则这个所写词的每个字母均应大写，如：XMLExample。比如你需要测试业务MobileBind，那么它的测试类的命名就是TestMobileBind比如你需要测试接口GetMobileBind，那么的测试类的命名就是TestGetMobileBind比如你需要测试类SetMobileBind.class,那么他的测试类的命名就是TestSetMobileBind2.测试用例的命名定义规范测试用例的命名规则是：test+用例操作_状态。单词的约定与测试类命名同。如:testSetMobileBind_NoSkyid。比如要测试的用例是“数据库用户信息不存在时,获取Mobile绑定消息”，那么它的测试用例名称就是testSetMobileBind_NoSkyid测试代码的组织3.测试程序的包名定义规范测试程序包的命名规则是：test.com.skymobi.项目名；测试公共类包的命名规则是：test.com.skymobi.commonjava包的名称都是由小写字母组成。测试项目，比如被测试的项目是skyups，那么测试类的包名就是test.com.skymobi.skyups。测试开发包，比如被测试类的包名是com.skymobi.util，那么测试类的包名就是test.com.skymobi.util。也就是说在被测试类的包名前加上“test.”，这就是测试类的包名。4.变量的命名规范测试程序的变量名均采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写，例如：MaxValue。变量名不应以下划线或美元符号开头，尽管这在语法上是允许的。变量名应简短且富于描述。变量名的选用应该易于记忆，即，能够指出其用途。尽量避免单个字符的变量名，除非是一次性的临时变量。5.常量的命名规范测试程序的常量名应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词。例如：MAX_VALUE单元测试代码和被测试代码使用一样的包，不同的目录。测试代码的组织待测试的类的介绍对应的测试类1.测试方法必须使用注解org.junit.Test修饰。2.测试方法必须使用publicvoid修饰，而且不能带有任何参数。运行测试用例在测试类上点击右键，在弹出菜单中选择RunAsJUnitTest。运行结果如下图所示：绿色的进度条提示我们，测试运行通过了单元测试的范围要全面，比如对边界值、正常值、错误值得测试；对代码可能出现的问题要全面预测完善后的测试用例再次测试JUnit运行界面提示我们有两个测试情况未通过测试（图4）——当首字母大写时得到的处理结果与预期的有偏差，造成测试失败（failure）；而当测试对null的处理结果时，则直接抛出了异常——测试错误（error）。JUnit将测试失败的情况分为两种：failure和error。Failure一般由单元测试使用的断言方法判断失败引起，它表示在测试点发现了问题；而error则是由代码异常引起，这是测试目的之外的发现，它可能产生于测试代码本身的错误（测试代码也是代码，同样无法保证完全没有缺陷），也可能是被测试代码中的一个隐藏的bug。修正被测试类JUnit深入Fixture：它是指在执行一个或者多个测试方法时需要的一系列公共资源或者数据，例如测试环境，测试数据等等。在编写单元测试的过程中，您会发现在大部分的测试方法在进行真正的测试之前都需要做大量的铺垫——为设计准备Fixture而忙碌。JUnit专门提供了设置公共Fixture的方法，同一测试类中的所有测试方法都可以共用它来初始化Fixture和注销Fixture。和编写JUnit测试方法一样，公共Fixture的设置也很简单，您只需要：使用注解org,junit.Before修饰用于初始化Fixture的方法。使用注解org.junit.After修饰用于注销Fixture的方法。保证这两种方法都使用publicvoid修饰，而且不能带有任何参数。遵循上面的三条原则，编写出的代码大体是这个样子：//初始化Fixture方法@Beforepublicvoidinit(){……}//注销Fixture方法@Afterpublicvoiddestroy(){……}Fixture方法级的Fixture示意方法级的Fixture问题:开销太大类级别的Fixture类级别的Fixture仅会在测试类中所有测试方法执行之前执行初始化，并在全部测试方法测试完毕之后执行注销方法（如下图）。代码范本如下：//类级别Fixture初始化方法@BeforeClasspublicstaticvoiddbInit(){……}//类级别Fixture注销方法@AfterClasspublicstaticvoiddbClose(){……}异常以及时间测试注解org.junit.Test中有两个非常有用的参数：expected和timeout。参数expected代表测试方法期望抛出指定的异常，如果运行测试并没有抛出这个异常，则JUnit会认为这个测试没有通过。这为验证被测试方法在错误的情况下是否会抛出预定的异常提供了便利。举例来说，方法supportDBChecker用于检查用户使用的数据库版本是否在系统的支持的范围之内，如果用户使用了不被支持的数据库版本，则会抛出运行时异常UnsupportedDBVersionException。测试方法supportDBChecker在数据库版本不支持时是否会抛出指定异常的单元测试方法大体如下：@Test(expected=UnsupportedDBVersionException.class)publicvoidunsupportedDBCheck(){……}注解org.junit.Test的另一个参数timeout，指定被测试方法被允许运行的最长时间应该是多少，如果测试方法运行时间超过了指定的毫秒数，则JUnit认为测试失败。这个参数对于性能测试有一定的帮助。例如，如果解析一份自定义的XML文档花费了多于1秒的时间，就需要重新考虑XML结构的设计，那单元测试方法可以这样来写：忽略测试方法JUnit提供注解org.junit.Ignore用于暂时忽略某个测试方法，因为有时候由于测试环境受限，并不能保证每一个测试方法都能正确运行。例如下面的代码便表示由于没有了数据库链接，提示JUnit忽略测试方法unsupportedDBCheck：测试断言参数如以下内容:message,expected-value,actual-valueassertEquals([Stringmessage],Objectexpected,Objectactual)判断是否相等，可以指定输出错误信息。第一个参数是期望值，第二个参数是实际的值。assertTrue/False([Stringmessage],Booleancondition)判断一个条件是true还是false。assertNotNull/Null([Stringmessage],Objectobj)判读一个对象是否非空(非空)。assertSame/NotSame([Stringmessage],Objectexpected,Objectactual)判断两个对象是否指向同一个对象。看内存地址。fail([Stringmessage])失败，可以有消息，也可以没有消息。Junit结构测试运行器又一个新概念出现了——测试运行器，JUnit中所有的测试方法都是由它负责执行的。JUnit为单元测试提供了默认的测试运行器，但JUnit并没有限制您必须使用默认的运行器。如果测试类没有显式的声明使用哪一个测试运行器，JUnit会启动默认的测试运行器执行测试类（比如上面提及的单元测试代码）。一般情况下，默认测试运行器可以应对绝大多数的单元测试要求；当使用JUnit提供的一些高级特性（例如即将介绍的两个特性）或者针对特殊需求定制JUnit测试方式时，显式的声明测试运行器就必不可少了。测试套件如果每次只能运行一个测试用例，那么又陷入了我们前面所谈到的传统测试的窘境：手工去运行一个个测试用例，测试套件专门为解决这一问题而来。它通过TestSuite对象将多个测试用例组装成到一个测试套件，则测试套件批量运行。需要特殊指出的是，可以把一个测试套件整个添加到另一个测试套件中，就象小筐装进大筐里变成一个箧一样。测试套件规则创建一个空类作为测试套件的入口。使用注解org.junit.runner.RunWith和org.junit.runners.Suite.SuiteClasses修饰这个空类。将org.junit.runners.Suite作为参数传入注解RunWith，以提示JUnit为此类使用套件运行器执行。将需要放入此测试套件的测试类组成数组作为注解SuiteClasses的参数。保证这个空类使用public修饰，而且存在公开的不带有任何参数的构造函数。测试套件参数化测试为了保证单元测试的严谨性，我们模拟了不同类型的字符串来测试方法的处理能力，为此我们编写大量的单元测试方法。可是这些测试方法都是大同小异：代码结构都是相同的，不同的仅仅是测试数据和期望值。有没有更好的方法将测试方法中相同的代码结构提取出来，提高代码的重用度，减少复制粘贴代码的烦恼？在以前的JUnit版本上，并没有好的解决方法，而现在您可以使用JUnit提供的参数化测试方式应对这个问题。参数化测试参数化测试的编写稍微有点麻烦（当然这是相对于JUnit中其它特性而言）：为准备使用参数化测试的测试类指定特殊的运行器org.junit.runners.Parameterized。为测试类声明几个变量，分别用于存放期望值和测试所用数据。为测试类声明一个使用注解org.juni