Java测试Junit和mockito

Mockito是一个开源mock框架，官网：http://mockito.org/，源码：https://github.com/mockito/mockito  

Junit是一个Java语言的单元测试框架，官网：http://junit.org/

这两个jar包的下载地址是：http://download.csdn.net/detail/bgk083/9043363

 

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

这里有几个关键点：①单元是人为规定的 ②单元测试是独立单元，要和其他部分相分离。

 

单元测试的作用？（参考http://blog.csdn.net/sunliduan/article/details/42026509）

1. 提高代码质量

        ----实现功能

        ----逻辑严密

   稍有信息素质的专业程序员总是追求着一件事情---写出优雅的代码。这里的优雅，不仅仅是指需求功能的准确实现，更是系统上线后的稳定和高性能。而测试用例的认真思考与书写，就给了程序员一个“深思熟虑”的机会，让我们在“做”之前先“想”好了。当然，这可能需要丰富的编程经验。不过我也相信，经验是一点点积累来的，所以从现在开始，为时不晚。

 

2. 减少调试时间

   我们以前的测试，基本上都是从web层开始，一条线的测试。首先这种测试需要我们打包部署后运行整个程序来执行，耗费时间较多；其次也是最重要的，出现错误后我们不能很快的定位是那一层的问题，只有一步一步的断点调试，方可定位到错误，这样调试的时间是很长的。

   而在Java中的单元测试，一般是对一个类的测试。而这个恰恰让coder极为迅速并且准确的定位错误的来源---就是本类！因此，极大的减少了我们调试的时间。

 

3. 隔离测试

   在一个大项目或者关系比较紧密的项目中，很有可能出现两个子系统之间的接口依赖，例如这次高校云平台的项目，其他子系统都需要基础系统为其提供接口，因此极可能会造成这种情况，前期开发中基础系统一直在开发接口，而自己的功能只能放后！

   怎么才能解决这个问题呢？隔离测试！它使得我们可以测试还未写完的代码（只要你又接口可使用），另外，隔离测试能帮助团队单元测试代码的一部分，而无需等待全部代码的完成。

 

 

单元测试一般有以下三种情况：普通测试、参数化测试和隔离测试。普通测试使用的是默认的运行器，而参数化测试用的是org.junit.runners.Parameterized，隔离测试会用到mockito。

（一）普通测试

待测方法：

 

[java]  view plain  copy

 

1. <span style="font-size:14px;">//加法    
2. public int add(int a, int b) {    
3.     return a + b;    
4. } </span>  

测试方法：

 

[java]  view plain  copy

 

1. <span style="font-size:14px;">@Test    
2. publicvoidtestAdd(){    
3.      
4. //--------------------第一种写法----------------------    
5. //（1）待测方法的“参数赋值”    
6. inta =1;    
7. intb=3;    
8.      
9. //（2）赋值后的“期望值”    
10. intexpectedReturn=6;    
11.      
12. //（3）调用待测方法，得到“实际值”    
13. intactualReturn = firstDemo.add(1, 3);    
14.      
15. //（4）通过断言，判断“期望值”和“实际值”是否相等    
16. assertEquals(expectedReturn,actualReturn);    
17.      
18. //---------------------第二种写法------------------------    
19. //assertEquals(4,firstDemo.add(1,3));                    
20.      
21. }  </span>  

 

测试方法的书写一般有四个步骤：（1）参数赋值（2）写出期望值（3）获取实际值（4）断言--比较期望值和实际值。

当参数情况较多时就需要进行参数化测试了。

 

（二）参数化测试

 

上面第一个普通测试，是针对一个方法只需要一个测试用例即可完成测试的情况。在实际项目中，我们会遇到一些分支语句，这时候一个测试用例已经不能满足我们覆盖全部分支语句了。所以我们就需要写多个测试用例，可是我们必须针对这个待测方法，写多个测试方法吗？这也太麻烦了吧！没有什么解决办法吗？如果是Junit3的话，我们只能这样做，可是从Junit4开始，加入了一个新的概念--参数化测试。这就为我们解决了这个问题。

   参数化测试主要包括五个步骤：

（1）为准备使用参数化测试的测试类指定特殊的运行器org.junit.runners.Parameterized。

   @RunWith(Parameterized.class)

（2）为测试类声明几个变量，分别用于存放期望值和测试所用数据，期望值可能只有一个，但测试数据变量可能有好几个，比如加法中有两个变量才能得出一个结果。

（3）为测试类声明一个带有参数的公共构造函数，并在其中为第二个环节中声明的几个变量赋值，构造方法是Junit调用的  ☆关键点☆

（4）为测试类声明一个使用注解org.junit.runners.Parameterized.Parameters修饰的，返回值为 java.util.Collection的公共静态方法，并在此方法中初始化所有需要测试的参数对。 ☆关键点☆

（5）编写测试方法，使用定义的变量作为参数进行测试。

测试方法：

 

[java]  view plain  copy

 

1. @RunWith(Parameterized.class)//第一步：<span style="color:#ff0000;">指定特殊的运行器org.junit.runners.Parameterized</span>    
2.      
3. public class FirstDemoTestParameterization {    
4.      
5.   //要测试的类    
6. private FirstDemo firstDemo;            
7.      
8. //第二步：为测试类声明几个变量，分别用于存放期望值和测试所用数据。    
9. private int input1;     
10. private boolean expected;    
11.      
12. @Before //执行每个测试方法之前都执行一次    
13. public void setUp() throws Exception {    
14.     firstDemo = newFirstDemo();    
15. }    
16.      
17.   //第三步：带有参数的公共构造函数，并在其中为声明的几个变量赋值。    
18.      
19.     public FirstDemoTestParameterization(int input1,boolean expected) {    
20.        this.input1 = input1;  //参数1    
21.        this.expected = expected;  //期待的结果值    
22.     }    
23.      
24. //-------------------（1）参数赋值 &&&（2）写出期望值----------------------------            
25.        
26. //第四步：为测试类声明一个注解@Parameters，返回值为Collection的公共静态方法，并初始化所有需要测试的参数对。    
27.   @Parameters    
28.    public static Collection prepareData() {    
29.        Object[][]object = { { -1,true }, { 13, true } };    //测试数据    
30.        returnArrays.asList(object); //将数组转换成集合返回    
31.     }    
32.        
33. @Test    
34.   public void testParameterization() {    
35. //-----------（3）获取实际值&&&（4）断言--比较期望值和实际值。---------------            
36. //第五步：编写测试方法，使用定义的变量作为参数进行测试。    
37.     assertEquals(expected,firstDemo.Parameterization(input1));    
38.   }    
39. }  

但有时候测试会依赖其他单元，而单元测试要独立测试，因此需要把其他单元隔离，就有了隔离测试。

 

Parameterized是在参数上实现了Suit——修饰一个测试类，但是可以提供多组构造函数的参数用于测试不同场景。

示例2：

 

[java]  view plain  copy

 

1. @RunWith(Parameterized.class)  
2. public class TestGenerateParams  
3. {  
4.        
5.     private String greeting;  
6.        
7.     public TestGenerateParams(String greeting)  
8.     {  
9.         super();  
10.         this.greeting = greeting;  
11.     }  
12.    
13.     @Test  
14.     public void testParams()  
15.     {  
16.         System.out.println(greeting);  
17.     }  
18.        
19.     /** 
20.      * 这里的返回至少是二维数组 
21.      * @return 
22.      */  
23.     @Parameters  
24.     public static List<String[]> getParams()  
25.     {  
26.         return  
27.                 Arrays.asList(new String[][]{{"hello"},   
28.                         {"hi"},   
29.                         {"good morning"},  
30.                         {"how are you"}});  
31.     }  
32. }  

输出结果：

[java]  view plain  copy

 

1. hello  
2. hi  
3. good morning  
4. how are you  

 

 

getParams提供一组参数，根据JUnit的生命周期，在每次运行测试方法的时候都会调用Constructor来创建一个实例，这里构造函数的参数就是通过Collection传入的。因此如你所见我们需要一个含有参数的构造函数用于接收参数，这个参数需要用于跑测试用例所以把它保存做类的变量；然后用@Parameters修饰我们提供参数的静态方法，它需要返回List<Object[]>，List包含的是参数组，Object[]即按顺序提供的一组参数，它会按照参数组一个一个的创建实例，相当于写了多个@Test。要想实现参数化测试，必须要有构造方法。

官方示例：

 

[java]  view plain  copy

 

1. @RunWith(Parameterized.class)  
2. public class FibonacciTest {  
3.     @Parameters  
4.     public static Collection<Object[]> data() {  
5.         return Arrays.asList(new Object[][] {       
6.                  { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 },{ 6, 8 }    
7.            });  
8.     }  
9.   
10.     private int fInput;  
11.   
12.     private int fExpected;  
13.   
14.     public FibonacciTest(int input, int expected) {  
15.         fInput= input;  
16.         fExpected= expected;  
17.     }  
18.   
19.     @Test  
20.     public void test() {  
21.         assertEquals(fExpected, Fibonacci.compute(fInput));  
22.     }  
23. }  

注：Each instance of FibonacciTest will be constructed using the two-argument constructor and the data values in the @Parameters method.

 

 

（三）隔离测试

隔离测试也是我们常用的一个防止多类之间依赖的测试。最基础的就是B层对D层的依赖。测试B层时，我们不可能还要跑D层，这样的话就不是单元测试。那么我们怎么来解决这个问题呢？我们不需要跑D层，但是又需要D层的返回值。隔离测试就帮助我们解决了这个问题。当我们依赖其他类时，不需要真实调用，只需mock出该类即可。

 

 

================================================================================================

 

 

介绍了以上这些，我们来看下Junit4的具体用法和Mockito的用法。

（一）Junit4

1.Junit4.x版本我们常用的注解：

A、@Before 注解：与junit3.x中的setUp()方法功能一样，在每个测试方法之前执行；

B、@After 注解：与junit3.x中的tearDown()方法功能一样，在每个测试方法之后执行；

C、@BeforeClass 注解：在所有方法执行之前执行；

D、@AfterClass 注解：在所有方法执行之后执行；

E、@Test(timeout = xxx) 注解：设置当前测试方法在一定时间内运行完，否则返回错误；

F、@Test(expected = Exception.class) 注解：设置被测试的方法是否有异常抛出。抛出异常类型为：Exception.class；

G、@Ignore 注解：注释掉一个测试方法或一个类，被注释的方法或类，不会被执行。

2.Junit4.x版本我们常用的断言：assertEquals、assertTrue/False、assertNotNull/Null、assertSame/NotSame、assertThat(这个用的比较多，可以参看Junit4官网)、fail等，断言如果抛出异常，就会中断该测试方法，对其他测试方法无影响。

关于AssertThat和Hamcrest可以看：http://www.blogjava.net/DLevin/archive/2012/05/12/377960.html、http://blog.csdn.net/shrekmu/article/details/3018392

3.Junit的生命周期

[java]  view plain  copy

 

1. public class HelloActionTest {  
2.     public HelloActionTest() {  
3.         System.out.println("Constructor");  
4.     }  
5.     @BeforeClass  
6.     public static void initClass() {  
7.         System.out.println("BeforeClass");  
8.     }  
9.     @Before  
10.     public void init() {  
11.         System.out.println("Before");  
12.     }  
13.       
14.     @Test  
15.     public void test1() {  
16.         System.out.println("test1");  
17.     }  
18.     @Test  
19.     public void test2() {  
20.         System.out.println("test2");  
21.     }  
22.       
23.     @After  
24.     public void after() {  
25.         System.out.println("after");  
26.     }  
27.     @AfterClass  
28.     public static void afterClass() {  
29.         System.out.println("afterClass");  
30.     }  
31. }  

运行结果：

[java]  view plain  copy

 

1. BeforeClass  
2. Constructor  
3. Before  
4. test1  
5. after  
6. Constructor  
7. Before  
8. test2  
9. after  
10. afterClass  

@BeforeClass：修饰static的方法，在整个类执行之前执行该方法一次。比如你的测试用例执行前需要一些高开销的资源（连接数据库）可以用@BeforeClass搞定。值得注意的是如果测试用例类的父类中也存在@BeforeClass修饰的方法，它将在子类的@BeforeClass之前执行。和静态代码块类似，但低于它的优先级，即如果有静态代码块，就先执行静态代码块
@AfterClass：同样修饰static的方法，在整个类执行结束前执行一次。如果你用@BeforeClass创建了一些资源现在是时候释放它们了。
@Before：修饰public void的方法，在每个测试用例（方法）执行时都会执行。
@After：修饰public void的方法，在每个测试用例执行结束后执行。
Constructor： 每个测试用例（即每个@Test)都会重新创建当前的Class实例，可以看到Constructor执行了两次。

具体的用法可参考http://junit.org/

 

（二）Mockito（用于模拟对象，隔离测试）

所谓的mock，就是指，如果我们写的代码依赖于某些对象，而这些对象又很难手动创建（即不知道如何初始化等，像HttpRequest等对象），那么就用一个虚拟的对象来测试。因为它传入的是一个class文件，所以static代码块还是会被运行，但构造函数，实例代码块都不会被执行

 

所谓打桩Stub，就是用来提供测试时所需要的测试数据,因为是mock的对象，所以可能有些方法并不能知道返回值，因此我们需要去假定返回值。可以对各种交互设置相应的回应，即对方法设置调用返回值，使用when(...).thenReturn(...)。

例如

[java]  view plain  copy

 

1. <span style="font-size:12px;">List list = mock(List.class);  
2. //因为mock出的list不知道有什么值，可以假定。  
3. when(list.get(0)).thenReturn("you get it");  
4. when(list.get(1)).thenReturn(new Exception);</span>  

验证方法的调用使用verify(...).xxxMethod(...)

整个框架就是围绕模拟（无论是模拟对象还是方法还是方法的参数）和验证（验证是否调用，调用顺序，调用次数等）

 

模拟 ：

1.1 stubbing

[java]  view plain  copy

 

1. //You can mock concrete classes, not only interfaces  
2.  LinkedList mockedList = mock(LinkedList.class);  
3.   
4.  //stubbing  
5.  when(mockedList.get(0)).thenReturn("first");  
6.  when(mockedList.get(1)).thenThrow(new RuntimeException());  
7.   
8.  //following prints "first"  
9.  System.out.println(mockedList.get(0));  
10.   
11.  //following throws runtime exception  
12.  System.out.println(mockedList.get(1));  
13.   
14.  //following prints "null" because get(999) was not stubbed  
15.  System.out.println(mockedList.get(999));  
16.   
17.  //Although it is possible to verify a stubbed invocation, usually it's just redundant  
18.  //If your code cares what get(0) returns then something else breaks (often before even verify() gets executed).  
19.  //If your code doesn't care what get(0) returns then it should not be stubbed.   
20.  verify(mockedList).get(0);  
21.    

默认情况下，对于所有有返回值且没有stub过的方法，mockito会返回相应的默认值。

对于内置类型会返回默认值，如int会返回0，布尔值返回false。对于其他type会返回null。重复多次stubbing，以最后一次为准。

1.2连续的stubbing

[java]  view plain  copy

 

1. when(mock.someMethod("some arg"))  
2.   .thenThrow(new RuntimeException())  
3.   .thenReturn("foo");  
4. *等价于when(mock.someMethod("some arg")).thenReturn("one","two","three")*/  
5. //First call: throws runtime exception:  
6. mock.someMethod("some arg");  
7.   
8. //Second call: prints "foo"  
9. System.out.println(mock.someMethod("some arg"));  
10.   
11. //Any consecutive call: prints "foo" as well (last stubbing wins).  
12. System.out.println(mock.someMethod("some arg"));  

1.3对于无返回值的stubbing的情况

[java]  view plain  copy

 

1. doThrow(new RuntimeException()).when(mockedList).clear();  
2.   
3.    //following throws RuntimeException:  
4.    mockedList.clear();  
5.    

2.Argument matchers

[java]  view plain  copy

 

1. //stubbing using built-in anyInt() argument matcher  
2. when(mockedList.get(anyInt())).thenReturn("element");  
3.   
4. //stubbing using custom matcher (let's say isValid() returns your own matcher implementation):  
5. when(mockedList.contains(argThat(isValid()))).thenReturn("element");  
6.   
7. //following prints "element"  
8. System.out.println(mockedList.get(999));  
9.   
10. //you can also verify using an argument matcher  
11. verify(mockedList).get(anyInt());  

注：如果你使用了参数匹配器，那么所有的参数都需要有匹配器给出

[java]  view plain  copy

 

1. verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));  
2.    //above is correct - eq() is also an argument matcher  
3.   
4. verify(mock).someMethod(anyInt(), anyString(), "third argument");  
5.    //above is incorrect - exception will be thrown because third argument is given without an argument matcher.  
6.    

验证：

1.验证方法调用次数

[java]  view plain  copy

 

1. //using mock  
2.  mockedList.add("once");  
3.   
4.  mockedList.add("twice");  
5.  mockedList.add("twice");  
6.   
7.  mockedList.add("three times");  
8.  mockedList.add("three times");  
9.  mockedList.add("three times");  
10.   
11.  //following two verifications work exactly the same - times(1) is used by default  
12.  verify(mockedList).add("once");  
13.  verify(mockedList, times(1)).add("once");  
14.   
15.  //exact number of invocations verification  
16.  verify(mockedList, times(2)).add("twice");  
17.  verify(mockedList, times(3)).add("three times");  
18.   
19.  //verification using never(). never() is an alias to times(0)  
20.  verify(mockedList, never()).add("never happened");  
21.   
22.  //verification using atLeast()/atMost()  
23.  verify(mockedList, atLeastOnce()).add("three times");  
24.  verify(mockedList, atLeast(2)).add("five times");  
25.  verify(mockedList, atMost(5)).add("three times");  

2.验证调用顺序

[java]  view plain  copy

 

1. // A. Single mock whose methods must be invoked in a particular order  
2.  List singleMock = mock(List.class);  
3.   
4.  //using a single mock  
5.  singleMock.add("was added first");  
6.  singleMock.add("was added second");  

[java]  view plain  copy

 

1. //create an inOrder verifier for a single mock   关键点  
2. InOrder inOrder = inOrder(singleMock);  
3.   
4. //following will make sure that add is first called with "was added first, then with "was added second"  
5. inOrder.verify(singleMock).add("was added first");  
6. inOrder.verify(singleMock).add("was added second");</span>  
7.   
8. // B. Multiple mocks that must be used in a particular order  
9. List firstMock = mock(List.class);  
10. List secondMock = mock(List.class);  
11.   
12. //using mocks  
13. firstMock.add("was called first");  
14. secondMock.add("was called second");  
15.   
16. //create inOrder object passing any mocks that need to be verified in order  
17. InOrder inOrder = inOrder(firstMock, secondMock);  
18.   
19. //following will make sure that firstMock was called before secondMock  
20. inOrder.verify(firstMock).add("was called first");  
21. inOrder.verify(secondMock).add("was called second");  
22.   
23. // Oh, and A + B can be mixed together at will  

注：验证顺序是要灵活变通的，一般你不需要去对每一个互动都去验证调用顺序，而只是在你感兴趣的互动上去验证调用顺序。

详细的可参考：http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html

 

总结：单元测试中一般要结合Junit和Mockito一起测试。

 

http://blog.csdn.net/bgk083/article/details/47962909