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。
（一）普通测试
待测方法：
//加法
public int add(int a, int b) {
return a + b;
} 测试方法：
@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));
} 测试方法的书写一般有四个步骤：（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)//第一步：指定特殊的运行器org.junit.runners.Parameterized
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 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 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));
}
} @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
@AfterClass：同样修饰static的方法，在整个类执行结束前执行一次。如果你用@BeforeClass创建了一些资源现在是时候释放它们了。
@Before：修饰public void的方法，在每个测试用例（方法）执行时都会执行。
@After：修饰public void的方法，在每个测试用例执行结束后执行。
Constructor： 每个测试用例（即每个@Test)都会重新创建当前的Class实例，可以看到Constructor执行了两次。
List list = mock(List.class);
//因为mock出的list不知道有什么值，可以假定。
when(list.get(0)).thenReturn("you get it");
when(list.get(1)).thenReturn(new Exception);//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"));1.3对于无返回值的stubbing的情况
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");// 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");
// 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详细的可参考：http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html