2024年10月junit4高级教程（如何使用junit4写单元测试用例）

　　⑴junit高级教程（如何使用junit写单元测试用例

　　⑵如何使用junit写单元测试用例

　　⑶我们在编写大型程序的时候，需要写成千上万个方法或函数，这些函数的功能可能很强大，但我们在程序中只用到该函数的一小部分功能，并且经过调试可以确定，这一小部分功能是正确的。但是，我们同时应该确保每一个函数都完全正确，因为如果我们今后如果对程序进行扩展，用到了某个函数的其他功能，而这个功能有bug的话，那绝对是一件非常郁闷的事情。所以说，每编写完一个函数之后，都应该对这个函数的方方面面进行测试，这样的测试我们称之为单元测试。传统的编程方式，进行单元测试是一件很麻烦的事情，你要重新写另外一个程序，在该程序中调用你需要测试的方法，并且仔细观察运行结果，看看是否有错。正因为如此麻烦，所以程序员们编写单元测试的热情不是很高。于是有一个牛人推出了单元测试包，大大简化了进行单元测试所要做的工作，这就是JUnit。本文简要介绍一下在Eclipse.中使用JUnit进行单元测试的方法。首先，我们来一个傻瓜式速成教程，不要问为什么，FollowMe，先来体验一下单元测试的快感！首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。这个类并不是很完美，我们故意保留了一些Bug用于演示，这些Bug在注释中都有说明。该类代码如下：packageandycpp;publilassCalculator…{privatestaticintresult;//静态变量，用于存储运行结果publicvoidadd(intn)…{result=result+n;}publicvoidsubstract(intn)…{result=result–;//Bug:正确的应该是result=result-n}publicvoidmultiply(intn)…{}//此方法尚未写好publicvoiddivide(intn)…{result=result/n;}publicvoidsquare(intn)…{result=n*n;}publicvoidsquareRoot(intn)…{for(;;);//Bug:死循环}publicvoidclear()…{//将结果清零result=;}publicintgetResult()…{returnresult;}}第二步，将JUnit单元测试包引入这个项目：在该项目上点右键，点“属性”，在弹出的属性窗口中，首先在左边选择“JavaBuildPath”，然后到右上选择“Libraries”标签，之后在最右边点击“AddLibrary…”按钮，如下图所示：然后在新弹出的对话框中选择JUnit并点击确定，如上图所示，JUnit软件包就被包含进我们这个项目了。第三步，生成JUnit测试框架：在Eclipse的PackageExplorer中用右键点击该类弹出菜单，选择“NewàJUnitTestCase”。在弹出的对话框中，进行相应的选择点击“下一步”后，系统会自动列出你这个类中包含的方法，选择你要进行测试的方法。此例中，我们仅对“加、减、乘、除”四个方法进行测试。之后系统会自动生成一个新类CalculatorTest，里面包含一些空的测试用例。你只需要将这些测试用例稍作修改即可使用。完整的CalculatorTest代码如下：packageandycpp;importstatic.junit.Assert.*;import.junit.Before;import.junit.Ignore;import.junit.Test;publilassCalculatorTest…{privatestatialculatorcalculator=newCalculator();BeforepublicvoidsetUp()throwsException…{calculator.clear();}TestpublicvoidtestAdd()…{calculator.add();calculator.add();assertEquals(,calculator.getResult());}TestpublicvoidtestSubstract()…{calculator.add();calculator.substract();assertEquals(,calculator.getResult());}Ignore(“Multiply()Notyetimplemented”)TestpublicvoidtestMultiply()…{}TestpublicvoidtestDivide()…{calculator.add();calculator.divide();assertEquals(,calculator.getResult());}}第四步，运行测试代码：按照上述代码修改完毕后，我们在CalculatorTest类上点右键，选择“RunAsàJUnitTest”来运行我们的测试，如下图所示：运行结果如下：进度条是红颜色表示发现错误，具体的测试结果在进度条上面有表示“共进行了个测试，其中个测试被忽略，一个测试失败”

　　⑷如何使用junit写单元测试用例

　　⑸packageandycpp;publilassCalculator{privatestaticintresult;//静态变量，用于存储运行结果publicvoidadd(intn){result=result+n;}publicvoidsubstract(intn){result=result-;//Bug:正确的应该是result=result-n}publicvoidmultiply(intn){}//此方法尚未写好publicvoiddivide(intn){result=result/n;}

　　⑹如何使用junit写单元测试用例

　　⑺JUnit是JUnit框架有史以来的最大改进，其主要目标便是利用Java的Annotation特性简化测试用例的编写。先简单解释一下什么是Annotation，这个单词一般是翻译成元数据。元数据是什么？元数据就是描述数据的数据。也就是说，这个东西在Java里面可以用来和public、static等关键字一样来修饰类名、方法名、变量名。修饰的作用描述这个数据是做什么用的，差不多和public描述这个数据是公有的一样。想具体了解可以看CoreJava。废话不多说了，直接进入正题。我们先看一下在JUnit中我们是怎样写一个单元测试的。比如下面一个类：publilassAddOperation{publicintadd(intx,inty){returnx+y;}}我们要测试add这个方法，我们写单元测试得这么写：importjunit.framework.TestCase;importstatic.junit.Assert.*;publilassAddOperationTestextendsTestCase{publicvoidsetUp()throwsException{}publicvoidtearDown()throwsException{}publicvoidtestAdd(){System.out.println(”add”);intx=;inty=;AddOperationinstance=newAddOperation();intexpResult=;intresult=instance.add(x,y);assertEquals(expResult,result);}}可以看到上面的类使用了JDK中的静态导入，这个相对来说就很简单，只要在import关键字后面加上static关键字，就可以把后面的类的static的变量和方法导入到这个类中，调用的时候和调用自己的方法没有任何区别。我们可以看到上面那个单元测试有一些比较霸道的地方，表现在：.单元测试类必须继承自TestCase。.要测试的方法必须以test开头。如果上面那个单元测试在JUnit中写就不会这么复杂。代码如下：importjunit.framework.TestCase;import.junit.After;import.junit.Before;import.junit.Test;importstatic.junit.Assert.*;/****authorbean*/publilassAddOperationTestextendsTestCase{publicAddOperationTest(){}BeforepublicvoidsetUp()throwsException{}AfterpublicvoidtearDown()throwsException{}Testpublicvoidadd(){System.out.println(”add”);intx=;inty=;AddOperationinstance=newAddOperation();intexpResult=;intresult=instance.add(x,y);assertEquals(expResult,result);}}我们可以看到，采用Annotation的JUnit已经不会霸道的要求你必须继承自TestCase了，而且测试方法也不必以test开头了，只要以Test元数据来描述即可。从上面的例子可以看到在JUnit中还引入了一些其他的元数据，下面一一介绍：Before：使用了该元数据的方法在每个测试方法执行之前都要执行一次。After：使用了该元数据的方法在每个测试方法执行之后要执行一次。注意：Before和After标示的方法只能各有一个。这个相当于取代了JUnit以前版本中的setUp和tearDown方法，当然你还可以继续叫这个名字，不过JUnit不会霸道的要求你这么做了。Test(expected=*.class)在JUnit.之前，对错误的测试，我们只能通过fail来产生一个错误，并在try块里面assertTrue（true来测试。现在，通过Test元数据中的expected属性。expected属性的值是一个异常的类型Test(timeout=xxx):该元数据传入了一个时间（毫秒给测试方法，如果测试方法在制定的时间之内没有运行完，则测试也失败。ignore：该元数据标记的测试方法在测试中会被忽略。当测试的方法还没有实现，或者测试的方法已经过时，或者在某种条件下才能测试该方法（比如需要一个数据库联接，而在本地测试的时候，数据库并没有连接，那么使用该标签来标示这个方法。同时，你可以为该标签传递一个String的参数，来表明为什么会忽略这个测试方法。比如：lgnore(“该方法还没有实现”)，在执行的时候，仅会报告该方法没有实现，而不会运行测试方法。在Eclipse中使用JUnit进行单元测试（初级篇我们在编写大型程序的时候，需要写成千上万个方法或函数，这些函数的功能可能很强大，但我们在程序中只用到该函数的一小部分功能，并且经过调试可以确定，这一小部分功能是正确的。但是，我们同时应该确保每一个函数都完全正确，因为如果我们今后如果对程序进行扩展，用到了某个函数的其他功能，而这个功能有bug的话，那绝对是一件非常郁闷的事情。所以说，每编写完一个函数之后，都应该对这个函数的方方面面进行测试，这样的测试我们称之为单元测试。传统的编程方式，进行单元测试是一件很麻烦的事情，你要重新写另外一个程序，在该程序中调用你需要测试的方法，并且仔细观察运行结果，看看是否有错。正因为如此麻烦，所以程序员们编写单元测试的热情不是很高。于是有一个牛人推出了单元测试包，大大简化了进行单元测试所要做的工作，这就是JUnit。本文简要介绍一下在Eclipse.中使用JUnit进行单元测试的方法。首先，我们来一个傻瓜式速成教程，不要问为什么，FollowMe，先来体验一下单元测试的快感！首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。这个类并不是很完美，我们故意保留了一些Bug用于演示，这些Bug在注释中都有说明。该类代码如下：packageandycpp;publilassCalculator…{privatestaticintresult;//静态变量，用于存储运行结果publicvoidadd(intn)…{result=result+n;}publicvoidsubstract(intn)…{result=result–;//Bug:正确的应该是result=result-n}publicvoidmultiply(intn)…{}//此方法尚未写好publicvoiddivide(intn)…{result=result/n;}publicvoidsquare(intn)…{result=n*n;}publicvoidsquareRoot(intn)…{for(;;);//Bug:死循环}publicvoidclear()…{//将结果清零result=;}publicintgetResult()…{returnresult;}}第二步，将JUnit单元测试包引入这个项目：在该项目上点右键，点“属性”，如图：在弹出的属性窗口中，首先在左边选择“JavaBuildPath”，然后到右上选择“Libraries”标签，之后在最右边点击“AddLibrary…”按钮，如下图所示：然后在新弹出的对话框中选择JUnit并点击确定，如上图所示，JUnit软件包就被包含进我们这个项目了。第三步，生成JUnit测试框架：在Eclipse的PackageExplorer中用右键点击该类弹出菜单，选择“NewàJUnitTestCase”。如下图所示：在弹出的对话框中，进行相应的选择，如下图所示：点击“下一步”后，系统会自动列出你这个类中包含的方法，选择你要进行测试的方法。此例中，我们仅对“加、减、乘、除”四个方法进行测试。如下图所示：之后系统会自动生成一个新类CalculatorTest，里面包含一些空的测试用例。你只需要将这些测试用例稍作修改即可使用。完整的CalculatorTest代码如下：packageandycpp;importstatic.junit.Assert.*;import.junit.Before;import.junit.Ignore;import.junit.Test;publilassCalculatorTest…{privatestatialculatorcalculator=newCalculator();BeforepublicvoidsetUp()throwsException…{calculator.clear();}TestpublicvoidtestAdd()…{calculator.add();calculator.add();assertEquals(,calculator.getResult());}TestpublicvoidtestSubstract()…{calculator.add();calculator.substract();assertEquals(,calculator.getResult());}Ignore(“Multiply()Notyetimplemented”)TestpublicvoidtestMultiply()…{}TestpublicvoidtestDivide()…{calculator.add();calculator.divide();assertEquals(,calculator.getResult());}}第四步，运行测试代码：按照上述代码修改完毕后，我们在CalculatorTest类上点右键，选择“RunAsàJUnitTest”来运行我们的测试，如下图所示：运行结果如下：进度条是红颜色表示发现错误，具体的测试结果在进度条上面有表示“共进行了个测试，其中个测试被忽略，一个测试失败”

　　⑻如何使用junit写单元测试用例

　　⑼Junit支持注解了，只要在要执行的方法前加Test即可，如：TestpublicvoidmultiplyPoundsByInteger(){assertEquals(,);}Junit增加了许多特性，主要是支持注解了：测试由原来的命名模式改变注解，即testXXX变为Test。其中Test还提供了额外的属性。如expected，表示期望抛出的异常数组比较改用Assert.assertArrayEquals套件测试也用注解替换通过Ignore，可以忽略某个方法或整个类的测试增加了新特性-理论机制（Theory,这个特性听起来很迷惑人,作用是使得开发人员从开始的定义测试用例的阶段就可以通过参数集（理论上是无限个参数对代码行为进行概括性的总结.开发人员都知道他们代码所想要实现的概括性的总的目的，理论使得他们只需要在一个地方就可以快速的指定这些目的，而不要将这些目的翻译成大量的独立的测试用例。提供了新的特性-假设机制（Assumption.此特性使用了Hamcrest库的类.本来Hamcrest是一个单独的测试组件,Junit也集成了一部分，但是并没有完全包含。建议使用junit独立的JAR文件，再单独引入hamcrest包。其实hamcrest的功能相当的强大，理解起来也非常的容易，是一个很不错的组件。它提供assertThat,assumeThat，assumeNotNull等假设语句，也提供is,not,both..and,either..or等用法，非常的灵活。Before,After,BeforeClass,AfterClass.这几个注解一看便知大概，Before表示每个测试方法执行前执行一次，而BeforeClass表示整个类测试前执行一次。不过需要注意的是，BeforeClass,AtferClass注解的方法必须是静态的。Junit提供了新的核心运行类MaxCore，相对于以前的JunitCore运行机制，这个类有一系列的优点，如从未测试过的方法优先测试，剩下的测试中，以前测试失败的方法优先测试，再其次，运行快的优先于运行慢的方法。

　　⑽测试的概念长期以来，我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在最终验收的时候编写测试文档。有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡UML、RUP、软件工程、CMM，目的只有一个，提高软件编写的质量。举一个极端的例子：如果你是一个超级程序设计师，一个传奇般的人物。（你可以一边喝咖啡，一边听着音乐，同时编写这操作系统中关于进程调度的模块，而且两天时间内就完成了！我真得承认，有这样的人。（那个编写UNIX中的vi器的家伙就是这种人。然而非常遗憾的是这些神仙们并没有留下如何修成正果的README。所以我们这些凡人－－在同一时间只能将注意力集中到若干点（据科学统计，我并不太相信，一般的人只能同时考虑最多个左右的问题，高手可以达到个左右，而不能既纵览全局又了解细节－－只能期望于其他的方式来保证我们所编写的软件质量。为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵（softwareentropy的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。你可能会争辩，在这个例子中，设计很好的状态实际上并不好，如果好的话，就不会发生你所说的情况。是的，看来你变聪明了，可惜你还应该注意到两个问题：)我们不能指望在恐龙纪元（大概是十年前设计的结构到了现在也能适用吧。)拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响，即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能，那么你很可能就失去了你的住房贷款和面包（对中国工程师来说也许是米饭或面条，要看你是南方人还是北方人。另外，需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味（不好意思...。我希望看到这片文章的兄弟姐妹能很容易地接受测试的概念，并付诸实施。所以有些地方写的有些夸张，欢迎对测试有深入理解的兄弟姐妹能体察民情，并不吝赐教。好了，我们现在言归正传。要测试，就要明白测试的目的。我认为测试的目的很简单也极具吸引力：写出高质量的软件并解决软件熵这一问题。想象一下，如果你写的软件和RichardStallman（GNU、FSF的头儿写的一样有水准的话，是不是很有成就感？如果你一致保持这种高水准，我保证你的薪水也会有所变动。测试也分类，白箱测试、黑箱测试、单元测试、集成测试、功能测试...。我们先不管有多少分类，如何分类。先看那些对我们有用的分类，关于其他的测试，有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何（How完成功能和完成什么样（What的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样（What的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。需要强调的是：测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterativeandincremental的开发过程。MartinFowler（有点儿像引用孔夫子的话甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说最简单的:测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：//将要被测试的类publilassCar{publicintgetWheels(){return;}}//执行测试的类publilasstestCar{publicstaticvoidmain（Stringargs){testCarmyTest=newtestCar();myTest.testGetWheels();}publictestGetWheels(){intexpectedWheels=;CarmyCar=Car();if(expectedWheels==myCar.getWheels())System.out.println(“test:getWheelsworksperfected!“);elseSystem.out.println(“test:getWheelsDOESN’Twork!“);}}如果你立即动手写了上面的代码，你会发现两个问题，第一，如果你要执行测试的类testCar，你必须必须手工敲入如下命令：d:》javatestCar％javatestCar即便测试如例示的那样简单，你也有可能不愿在每次测试的时候都敲入上面的命令，而希望在某个集成环境中(IDE)点击一下鼠标就能执行测试。后面的章节会介绍到这些问题。第二，如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准。没有人希望查看别人是如何设计测试类的。如果每个人都有不同的设计测试类的方法，光维护被测试的类就够烦了，谁还顾得上维护测试类？另外有一点我不想提，但是这个问题太明显了，测试类的代码多于被测试的类！这是否意味这双倍的工作？不！不论被测试类－Car的getWheels方法如何复杂，测试类－testCar的testGetWheels方法只会保持一样的代码量。提高软件的质量并解决软件熵这一问题并不是没有代价的。testCar就是代价。我们目前所能做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。好了，你所需要的就是JUnit。一个OpenSource的项目。用其主页上的话来说就是：“JUnit是由ErichGamma和KentBeck编写的一个回归测试框架（regressiontestingwork。用于Java开发人员编写单元测试之用。”所谓框架就是ErichGamma和KentBeck定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也就是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试就是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。通过回归测试我们抓住了这条大Bug。回归测试框架-JUnit通过前面的介绍，我们对JUnit有了一个大概的轮廓。知道了它是干什么的。现在让我们动手改写上面的测试类testCar使其符合Junit的规范－－能在JUnit中运行。//执行测试的类（JUnit版importjunit.work.*;publilasstestCarextendsTestCase{protectedintexpectedWheels;protectedCarmyCar;publictestCar(Stringname){super(name);}protectedvoidsetUp(){expectedWheels=;myCar=newCar();}publicstaticTestsuite(){/**thetypesafeway*TestSuitesuite=newTestSuite();suite.addTest(newtestCar(“Car.getWheels“){protectedvoidrunTest(){testGetWheels();}});returnsuite;*//**thedynamicway*/returnnewTestSuite(testCar.class);}publicvoidtestGetWheels(){assertEquals(expectedWheels,myCar.getWheels());}}改版后的testCar已经面目全非。先让我们了解这些改动都是什么含义，再看如何执行这个测试。》import语句，引入JUnit的类。（没问题吧》继承TestCase。可以暂时将一个TestCase看作是对某个类进行测试的方法的集合。详细介绍请参看JUnit资料》setUp()设定了进行初始化的任务。我们以后会看到setUp会有特别的用处。》testGetWheeels()对预期的值和myCar.getWheels()返回的值进行比较，并打印比较的结果。assertEquals是junit.work.Assert中所定义的方法，junit.work.TestCase继承了junit.work.Assert。》suite()是一个很特殊的静态方法。JUnit的TestRunner会调用suite方法来确定有多少个测试可以执行。上面的例子显示了两种方法：静态的方法是构造一个内部类，并利用构造函数给该测试命名(testname,如Car.getWheels)，其覆盖的runTest()方法，指明了该测试需要执行那些方法－－testGetWheels()。动态的方法是利用内省（reflection来实现runTest()，找出需要执行那些测试。此时测试的名字即是测试方法（testmethod，如testGetWheels的名字。JUnit会自动找出并调用该类的测试方法。》将TestSuite看作是包裹测试的一个容器。如果将测试比作叶子节点的话，TestSuite就是分支节点。实际上TestCase，TestSuite以及TestSuite组成了一个positePattern。JUnit的文档中有一篇专门讲解如何使用Pattern构造Junit框架。有兴趣的朋友可以查看JUnit资料。如何运行该测试呢？手工的方法是键入如下命令：d:》javajunit.textui.TestRunnertestCar％javajunit.textui.TestRunnertestCar别担心你要敲的字符量，以后在IDE中，只要点几下鼠标就成了。运行结果应该如下所示，表明执行了一个测试，并通过了测试：.Time:OK(tests)如果我们将Car.getWheels()中返回的的值修改为，模拟出错的情形，则会得到如下结果：.FTime:Therewasfailure:)testGetWheels(testCar)junit.work.AssertionFailedError:expected:《》butwas:《》attestCar.testGetWheels(testCar.java:)FAILURES!!!Testsrun:,Failures:,Errors:注意：Time上的小点表示测试个数，如果测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。注意，在模拟出错的测试中，我们会得到详细的测试报告“expected:《》butwas:《》”，这足以告诉我们问题发生在何处。下面就是你调试，测试，调试，测试...的过程，直至得到期望的结果。DesignbyContract（这句话我没法翻译DesignbyContract本是BertrandMeyer（Eiffel语言的创始人开发的一种设计技术。我发现在JUnit中使用DesignbyContract会带来意想不到的效果。DesignbyContract的核心是断言（assersion。断言是一个布尔语句，该语句不能为假，如果为假，则表明出现了一个bug。DesignbyContract使用三种断言：前置条件（pre-conditions、后置条件（post-conditions和不变式（invariants这里不打算详细讨论DesignbyContract的细节，而是希望其在测试中能发挥其作用。前置条件在执行测试之前可以用于判断是否允许进入测试，即进入测试的条件。如expectedWheels》,myCar!=null。后置条件用于在测试执行后判断测试的结果是否正确。如expectedWheels==myCar.getWheels()。而不变式在判断交易(Transaction)的一致性（consistency方面尤为有用。我希望JUnit可以将DesignbyContract作为未来版本的一个增强。Refactoring（这句话我依然没法翻译Refactoring本来与测试没有直接的联系，而是与软件熵有关，但既然我们说测试能解决软件熵问题，我们也就必须说出解决之道。（仅仅进行测试只能发现软件熵，Refactoring则可解决软件熵带来的问题。软件熵引出了一个问题：是否需要重新设计整个软件的结构？理论上应该如此，但现实不允许我们这么做。这或者是由于时间的原因，或者是由于费用的原因。重新设计整个软件的结构会给我们带来短期的痛苦。而不停地给软件打补丁甚至是补丁的补丁则会给我们带来长期的痛苦。（不管怎样，我们总处于水深火热之中Refactoring是一个术语，用于描述一种技术，利用这种技术我们可以免于重构整个软件所带来的短期痛苦。当你refactor时，你并不改变程序的功能，而是改变程序内部的结构，使其更易理解和使用。如：该变一个方法的名字，将一个成员变量从一个类移到另一个类，将两个类似方法抽象到父类中。所作的每一个步都很小，然而－个小时的Refactoring工作可以使你的程序结构更适合目前的情况。Refactoring有一些规则：》不要在加入新功能的同时refactor已有的代码。在这两者间要有一个清晰的界限。如每天早上-个小时的Refactoring，其余时间添加新的功能。》在你开始Refactoring前，和Refactoring后都要保证测试能顺利通过。否则Refactoring没有任何意义。》进行小的Refactoring，大的就不是Refactoring了。如果你打算重构整个软件，就没有必要Refactoring了。只有在添加新功能和调试bug时才又必要Refactoring。不要等到交付软件的最后关头才Refactoring。那样和打补丁的区别不大。Refactoring用在回归测试中也能显示其威力。要明白，我不反对打补丁，但要记住打补丁是应该最后使用的必杀绝招。（打补丁也需要很高的技术，详情参看微软网站IDE对JUnit的支持目前支持JUnit的JavaIDE包括IDE方式个人评价（－，满分ForteforJava.EnterpriseEditionplug-inJBuilderEnterpriseEditionintegratedwithIDEVisualAgeforJavasupportN/A在IDE中如何使用JUnit,是非常具体的事情。不同的IDE有不同的使用方法。一旦理解了JUnit的本质，使用起来就十分容易了。所以我们不依赖于具体的IDE，而是集中精力讲述如何利用JUnit编写单元测试代码。心急的人可参看资料。

　　⑾JUnit注解解释.Test:测试方法，测试程序会运行的方法，后边可以跟参数代表不同的测试，如(expected=XXException.class)异常测试，(timeout=xxx)超时测试.Ignore:被忽略的测试方法.Before:每一个测试方法之前运行.After:每一个测试方法之后运行.BeforeClass:所有测试开始之前运行.AfterClass:所有测试结束之后运行fail方法是指测试失败assertEquals测试个参数是否相等，具体参考相应API

　　⑿如何用Junit测试Spring框架下配置的类

　　⒀如何用Junit测试Spring框架下配置的类

　　⒁前几天，我们在做Junit的单元测试时，遇到了问题，就是Junit无法获得spring的配置环境，即Junit无法得到Spring创建的类实例。在查阅了网上的一些资料和同事的帮助下，成功的解决了此问题。步骤如下：建立一个test的目录，在此目录下放置所有的JunitTestCase类和TestCase的配置文件将项目中的Spring配置文件(默认名称为applicationContext.xml)复制到test目录下，并重新命名为JunitTestConf.xml。根据Junit测试的需要修改JunitTestConf.xml文件中的内容，如数据库连接等。新建一个名为SpringConfForTest.java的类，在此类中配置Spring启动所需的配置文件，并启动Spring。此类的内容如下：packagetest;import.junit.AfterClass;import.junit.BeforeClass;import.junit.Test;import.springframework.context.ApplicationContext;import.springframework.context.support.ClassPathXmlApplicationContext;import.soma.global.WebContextHolder;publilassSpringConfForTest{BeforeClasspublicstaticvoidsetUpBeforeClass()throwsException{//Spring启动所需要的配置参数文件,其中test/JunitTestConf.xml文件中保存了数据库连接等参数,可根据具体情况做修改String{“test/JunitTestConf.xml“,“/soma/conf/applicationContext-dao-hr.xml“,“/soma/conf/applicationContext-dao.xml“,“/soma/conf/applicationContext-dao-bug.xml“,“/soma/conf/applicationContext-dao-change.xml“,“/soma/conf/applicationContext-dao-mon.xml“,“/soma/conf/applicationContext-service-hr.xml“};//启动Spring，得到Spring环境上下文ApplicationContextctx=newClassPathXmlApplicationContext(paths);//在此类启动时，将Spring环境上下文保存到单根类WebContextHolder中,以提供给其它的测试类使用WebContextHolder.getInstence().setApplicationContext(ctx);}AfterClasspublicstaticvoidtearDownAfterClass()throwsException{}Testpublicvoidtest(){//必须要写一个test空方法，否则SpringConfForTest类不会启动}}新建TestSuite类，类名为AllTests，类的内容如下所示：packagetest;importjunit.framework.Test;importjunit.framework.TestSuite;import.junit.runner.RunWith;import.junit.runners.Suite;importtest..soma.domain.busilogic.hr.HrBusiLogicTest;importtest..soma.domain.service.hr.checkOverTimeDateTest;RunWith(Suite.class)Suite.SuiteClasses({SpringConfForTest.class,HrBusiLogicTest.class,checkOverTimeDateTest.class})/***批量执行Junit测试类，把类名写入到上面的Suite.SuiteClasses({})中，用逗号分隔*/publilassAllTests{publicstaticTestsuite(){TestSuitesuite=newTestSuite(“Testfortest“);//$JUnit-BEGIN$//$JUnit-END$returnsuite;}}注意：将SpringConfForTest.class放在第一个执行，以启动Spring配置环境，把自己的TestCase类放到后面，用逗号分开。在测试时，只要执行这个TestSuite类就可以了。写自己的TestCase类，以CheckOverTimeDateTest.java为例子，文件内容如下：publilassCheckOverTimeDateTest{privatestaticHrTbovertimeManagerhrTbovertimeManager;privatestaticExcuteSqlDAOexcuteSqlDAO;BeforeClasspublicstaticvoidsetUpBeforeClass()throwsException{//从Spring上下文中得到hrTbovertimeManager接口类的实例hrTbovertimeManager=(HrTbovertimeManager)BeanUtil.getBean(“hrTbovertimeManager“);excuteSqlDAO=(ExcuteSqlDAO)BeanUtil.getBean(“excuteSqlDAO“);}TestpublicvoidtestGetProjectList()throwsException{List《OvertimeDetailValue》overtimeDetailValueList=newArrayList《OvertimeDetailValue》();intindex=;for(inti=;i《=index;i++){OvertimeDetailValueovertimeDetailValue=newOvertimeDetailValue();overtimeDetailValue.setOtApplyDate(“--“+i);overtimeDetailValueList.add(overtimeDetailValue);}StringresultStr=hrTbovertimeManager.checkOverTimeDate(overtimeDetailValueList);assertEquals(“false“,resultStr);}/***导入-月份出勤记录excel文件，返回null表示导入成功,需要先删除月份的数据*/TestpublicvoidtestSaveExcelDutyInformation()throwsException{//在导入月份出勤记录前先删除月份的记录，执行deletefromhr_tbdutyinformation;excuteSqlDAO.excuteSql(“deletefromhr_tbdutyinformationwheredutydate》=’--’anddutydate《=’--’“);//System.out.println(“----------“+System.getProperty(“user.dir“)+“/src/test/duty.xls“);StringfileName=System.getProperty(“user.dir“)+“/src/test/duty.xls“;assertNull(hrTbdutyInformationManager.saveExcelDutyInformation(fileName));}}说明：BeanUtil.getBean(““)相当于WebContextHolder.getInstence().getApplicationContext().getBean(““),只是对此方法做了封装。在Eclipse中，启动AllTests，选择“RunAsJunitTest”，即可先启动Spring环境，再依次运行你自己所写的JunitTestCase

　　⒂intellijidea怎么部署junit

　　⒃步骤：一、在项目的AndroidManifest.xml文件中做如下更改：在application节点下添加《uses-libraryandroid:name=“android.test.runner“/》，如图：在根节点下添加如下内容：其中targetPackage跟你所在项目的包名相同（参见你的AppManifest.xml文件顶部：二、为你所在项目添加如下jar包引用、junit-.、harmcrest-core-.、annotations三、调整项目对jar包的引用顺序做这个调整是因为我们使用的AndroidAPI中包含了JUnit.，默认SDK是放在最前面的，否则代码中的Junit会被认为是Junit.,那你就只能使用Junit的测试方式了。四、在项目目录树中，创建一个与src平级的目录用于存放所有的测试类。简单起见我使用的是tests.除了创建目录，我们还需要指定新创建的目录为测试根目录：右键tests目录，选择’MarkDirectoryAs’---》’TestSourcesRoot’五、在你的测试根目录下创建你的测试分类目录及具体的测试类在测试类内部你需要的只是给测试方法加上Test标注。六、运行你的测试、在代码界面，在你的测试方法体中点击右键，在弹出的菜单中选中以JUnit的方式运行这种方式非常适合刚写完测试，亟待看到某个测试的运行结果的场景。还有一种使用快捷键的方式来单独运行某个测试，我们只需要将文本焦点切换到某个测试方法中，然后在使用组合键Ctrl+Shift+F就可以达到同上面一样的测试效果。、运行Configuration点击Configuration按钮，在弹出界面中按如下步骤创建一个JUnit运行配置

　　⒄如何使用junit写单元测试用例

　　⒅JUnit是JUnit框架有史以来的最大改进，其主要目标便是利用Java的Annotation特性简化测试用例的编写。元数据就是描述数据的数据。也就是说，这个东西在Java里面可以用来和public、static等关键字一样来修饰类名、方法名、变量名。

　　⒆如何使用junit写单元测试用例

　　⒇首先新建一个项目叫JUnit_Test，我们编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。这个类并不是很完美，我们故意保留了一些Bug用于演示，这些Bug在注释中都有说明。该类代码如下：packageandycpp;publilassCalculator{privatestaticintresult;//静态变量，用于存储运行结果publicvoidadd(intn){result=result+n;}publicvoidsubstract(intn){