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。
(一)普通测试
待测方法:
<span style="font-size:14px;">//加法 public int add(int a, int b) { return a + b; } </span>
测试方法:
<span style="font-size:14px;">@Test publicvoidtestAdd(){ //--------------------第一种写法---------------------- //(1)待测方法的“参数赋值” inta =1; intb=3; //(2)赋值后的“期望值” intexpectedReturn=6; //(3)调用待测方法,得到“实际值” intactualReturn = firstDemo.add(1, 3); //(4)通过断言,判断“期望值”和“实际值”是否相等 assertEquals(expectedReturn,actualReturn); //---------------------第二种写法------------------------ //assertEquals(4,firstDemo.add(1,3)); } </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)编写测试方法,使用定义的变量作为参数进行测试。
测试方法:
@RunWith(Parameterized.class)//第一步:<span style="color:#ff0000;">指定特殊的运行器org.junit.runners.Parameterized</span> public class FirstDemoTestParameterization { //要测试的类 private FirstDemo firstDemo; //第二步:为测试类声明几个变量,分别用于存放期望值和测试所用数据。 private int input1; private boolean expected; @Before //执行每个测试方法之前都执行一次 public void setUp() throws Exception { firstDemo = newFirstDemo(); } //第三步:带有参数的公共构造函数,并在其中为声明的几个变量赋值。 public FirstDemoTestParameterization(int input1,boolean expected) { this.input1 = input1; //参数1 this.expected = expected; //期待的结果值 } //-------------------(1)参数赋值 &&&(2)写出期望值---------------------------- //第四步:为测试类声明一个注解@Parameters,返回值为Collection的公共静态方法,并初始化所有需要测试的参数对。 @Parameters public static Collection prepareData() { Object[][]object = { { -1,true }, { 13, true } }; //测试数据 returnArrays.asList(object); //将数组转换成集合返回 } @Test public void testParameterization() { //-----------(3)获取实际值&&&(4)断言--比较期望值和实际值。--------------- //第五步:编写测试方法,使用定义的变量作为参数进行测试。 assertEquals(expected,firstDemo.Parameterization(input1)); } }
但有时候测试会依赖其他单元,而单元测试要独立测试,因此需要把其他单元隔离,就有了隔离测试。
Parameterized是在参数上实现了Suit——修饰一个测试类,但是可以提供多组构造函数的参数用于测试不同场景。
示例2:
@RunWith(Parameterized.class) public class TestGenerateParams { private String greeting; public TestGenerateParams(String greeting) { super(); this.greeting = greeting; } @Test public void testParams() { System.out.println(greeting); } /** * 这里的返回至少是二维数组 * @return */ @Parameters public static List<String[]> getParams() { return Arrays.asList(new String[][]{{"hello"}, {"hi"}, {"good morning"}, {"how are you"}}); } }输出结果:
hello hi good morning how are you
官方示例:
@RunWith(Parameterized.class) public class FibonacciTest { @Parameters public static Collection<Object[]> data() { return Arrays.asList(new Object[][] { { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 },{ 6, 8 } }); } private int fInput; private int fExpected; public FibonacciTest(int input, int expected) { fInput= input; fExpected= expected; } @Test public void test() { assertEquals(fExpected, Fibonacci.compute(fInput)); } }注: 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版本我们常用的注解:
public class HelloActionTest { public HelloActionTest() { System.out.println("Constructor"); } @BeforeClass public static void initClass() { System.out.println("BeforeClass"); } @Before public void init() { System.out.println("Before"); } @Test public void test1() { System.out.println("test1"); } @Test public void test2() { System.out.println("test2"); } @After public void after() { System.out.println("after"); } @AfterClass public static void afterClass() { System.out.println("afterClass"); } }运行结果:
BeforeClass Constructor Before test1 after Constructor Before test2 after afterClass@BeforeClass:修饰static的方法,在整个类执行之前执行该方法一次。比如你的测试用例执行前需要一些高开销的资源(连接数据库)可以用@BeforeClass搞定。值得注意的是如果测试用例类的父类中也存在@BeforeClass修饰的方法,它将在子类的@BeforeClass之前执行。和静态代码块类似,但低于它的优先级,即如果有静态代码块,就先执行静态代码块
<span style="font-size:12px;">List list = mock(List.class); //因为mock出的list不知道有什么值,可以假定。 when(list.get(0)).thenReturn("you get it"); when(list.get(1)).thenReturn(new Exception);</span>
//You can mock concrete classes, not only interfaces LinkedList mockedList = mock(LinkedList.class); //stubbing when(mockedList.get(0)).thenReturn("first"); when(mockedList.get(1)).thenThrow(new RuntimeException()); //following prints "first" System.out.println(mockedList.get(0)); //following throws runtime exception System.out.println(mockedList.get(1)); //following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999)); //Although it is possible to verify a stubbed invocation, usually it's just redundant //If your code cares what get(0) returns then something else breaks (often before even verify() gets executed). //If your code doesn't care what get(0) returns then it should not be stubbed. verify(mockedList).get(0);
默认情况下,对于所有有返回值且没有stub过的方法,mockito会返回相应的默认值。
对于内置类型会返回默认值,如int会返回0,布尔值返回false。对于其他type会返回null。重复多次stubbing,以最后一次为准。
1.2连续的stubbing
when(mock.someMethod("some arg")) .thenThrow(new RuntimeException()) .thenReturn("foo"); /*等价于when(mock.someMethod("some arg")).thenReturn("one","two","three")*/ //First call: throws runtime exception: mock.someMethod("some arg"); //Second call: prints "foo" System.out.println(mock.someMethod("some arg")); //Any consecutive call: prints "foo" as well (last stubbing wins). System.out.println(mock.someMethod("some arg"));
doThrow(new RuntimeException()).when(mockedList).clear(); //following throws RuntimeException: mockedList.clear();
2.Argument matchers
//stubbing using built-in anyInt() argument matcher when(mockedList.get(anyInt())).thenReturn("element"); //stubbing using custom matcher (let's say isValid() returns your own matcher implementation): when(mockedList.contains(argThat(isValid()))).thenReturn("element"); //following prints "element" System.out.println(mockedList.get(999)); //you can also verify using an argument matcher verify(mockedList).get(anyInt());注:如果你使用了参数匹配器,那么所有的参数都需要有匹配器给出
verify(mock).someMethod(anyInt(), anyString(), eq("third argument")); //above is correct - eq() is also an argument matcher verify(mock).someMethod(anyInt(), anyString(), "third argument"); //above is incorrect - exception will be thrown because third argument is given without an argument matcher.
//using mock mockedList.add("once"); mockedList.add("twice"); mockedList.add("twice"); mockedList.add("three times"); mockedList.add("three times"); mockedList.add("three times"); //following two verifications work exactly the same - times(1) is used by default verify(mockedList).add("once"); verify(mockedList, times(1)).add("once"); //exact number of invocations verification verify(mockedList, times(2)).add("twice"); verify(mockedList, times(3)).add("three times"); //verification using never(). never() is an alias to times(0) verify(mockedList, never()).add("never happened"); //verification using atLeast()/atMost() verify(mockedList, atLeastOnce()).add("three times"); verify(mockedList, atLeast(2)).add("five times"); verify(mockedList, atMost(5)).add("three times");2.验证调用顺序
// A. Single mock whose methods must be invoked in a particular order List singleMock = mock(List.class); //using a single mock singleMock.add("was added first"); singleMock.add("was added second");
//create an inOrder verifier for a single mock 关键点 InOrder inOrder = inOrder(singleMock); //following will make sure that add is first called with "was added first, then with "was added second" inOrder.verify(singleMock).add("was added first"); inOrder.verify(singleMock).add("was added second");</span> // B. Multiple mocks that must be used in a particular order List firstMock = mock(List.class); List secondMock = mock(List.class); //using mocks firstMock.add("was called first"); secondMock.add("was called second"); //create inOrder object passing any mocks that need to be verified in order InOrder inOrder = inOrder(firstMock, secondMock); //following will make sure that firstMock was called before secondMock inOrder.verify(firstMock).add("was called first"); inOrder.verify(secondMock).add("was called second"); // Oh, and A + B can be mixed together at will注:验证顺序是要灵活变通的,一般你不需要去对每一个互动都去验证调用顺序,而只是在你感兴趣的互动上去验证调用顺序。