前言
世面上测试的工具还是比较多的。本人用mock模拟测试用的比较多。所以一种用好了，其实都是大同小异。可以自测就可以了
关于单元测试的命名
测试类的命名规范：被测试类的类名+Test后缀。
测试用例的命名：由于一个被测试单元可能对应着不同的场景，因此测试用例应根据场景命名。比如某测试用例的场景为“当参数不合法时抛出异常”，则可以命名为
“throwExceptionBy异常名称”.
变量命名：测试一个单元时，预期的结果命名expectedResult，实际结果命名为actualResult 所有预期的都以expected为前缀
使用mockito
所谓的mock就是创建一个类的模拟的对象，在测试环境中，用来替换掉真实的对象，以达到两个目的
- 1.验证这个对象的某些方法的调用情况，调用了多少次，参数是什么等等
- 2.指定这个对象的某些方法的行为，返回特定的值，或者是执行特定的动作
导入依赖
MVN仓库连接： http://mvnrepository.com/artifact/org.mockito/mockito-a.
版本选择稳定最新的即可
图文讲解打桩–关于打桩
虽然mockedList是模仿出来的,但是我们设置的打桩以及返回值.那么他就会返回对应的期望值
如果输出一个我没有打桩的下标
返回结果为 null
参数匹配器
简单说下为何要用参数匹配器，如果参数比较多，我不可能一个个去给他设定，我需要批量设定，比如 get（1到100）的参数都打桩返回 “first” 在这种情况下，就需要使用参数匹配器
any匹配所有对应的类型
常用的匹配字符列表
anyBoolean,
anyByte,
anyChar,
anyCollection,
anyCollectionOf,
anyDouble,
anyFloat,
anyInt, anyList,
anyListOf, anyLong,
anyMap, anyMapOf,
anyObject,
anySet,
anySetOf,
anyShort,
anyString,
anyVararg.
any匹配参数自定义
Mockito 中，参数常常是自定义的比如是某 个 DTO 等 。 可 以 使 用 any(DTO.class) 比如 anyInt() 也 可 以 写 成 any(Integer.class)，效果等同.
verify行为验证
模拟出了一个List，List添加了一个元素为 “ 1 ” 验证是否增加了元素 ‘ 1 ’
如果确认成功那么测试通过，否则报错。
验证行为发生的次数
验证对象行为
说明
对于一个 mock 出来的对象，在代码执行结束后，需要验证其相关行为是否发生。被 mock的对象一旦创建，Mock 框架将会记录其所有行为，我们可以有针对性地选择一些进行验证。
示例
示例解析 当前示例中，我们 Mock 一个实例 mockedList，后两句的 verify 验证 mockedList
是否执行了 add 和 clear 两个行为。verify 用于验证对象的行为；
验证行为发生的
说明
一个对象的某个行为在一段执行逻辑中，有可能会发生多次，在验证时需要对其执行次数进行验证。
@Test
public void testDemoOne() {
List mockedList = mock(List.class);
mockedList.add("once");
mockedList.add("twice");
mockedList.add("twice");
mockedList.add("three times");
mockedList.add("three times");
mockedList.add("three times");
//下面这两种使用方法效果是一样的。默认是 times(1)
Mockito.verify(mockedList).add("once");
Mockito.verify(mockedList, times(1)).add("once");
//次数验证 是否添加两次，是否添加三次
Mockito.verify(mockedList, times(2)).add("twice");
Mockito.verify(mockedList, times(3)).add("three times");
//使用 never(). never() 是 times(0)的别名，两者效果等同
Mockito.verify(mockedList, never()).add("never happened");
//使用 atLeast()
Mockito.verify(mockedList, atLeastOnce()).add("three times");
}
times(1)是默认的，所以使用时可以省略
测试预期异常
说明
测试代码中期望的异常抛出
ublic class DemoOneTest {
// 允许抛出异常初始化
@Rule
public ExpectedException thrown = ExpectedException.none();
@Test
public void vote_throws_IllegalArgumentException_for_zero_age() {
Student student = new Student();
//期望的异常类型为 IllegalArgumentException
thrown.expect(IllegalArgumentException.class);
//期望的异常信息：age should be +ve
thrown.expectMessage("age should be +ve");
student.vote(0);
}
}
示例解析
执行 student.vote(0)时，如果确实有期望的异常，则测试通过。否则，测试失败
为了防止图片不完整，我用代码实例
用@Mock 简化 mock 对象的
说明
在此前的例子，mock 一个对象时，用的是 mock(List.class)等，本节将描述如何简化
创建，这将使我们的代码更简洁、更易读。
//等同于 ArticleCalculator calculator=mock(ArticleCalculator.clss);
@Mock
private ArticleCalculator calculator;
@Mock
private ArticleDatabase database;
@Mock
private UserProvider userProvider;
private ArticleManager manager;示例解析
需要注意的是，使用该方法创建 mock 对象时，需要在测试用例执行前执行以下代码。通常，这句代码可以放在测试基类或者@Before 中。
MockitoAnnotations.initMocks(this);意思为初始化Mock环境，如果使用@Mock注解需要在@Test之前初始化MOCK，如果涉及的序列码。请使用
@BeforeClass
public void initMock() {
MockitoAnnotations.initMocks(this);
}否者可以使用
@Rule
public PowerMockRule rule = new PowerMockRule();同样实现初始化代码；
用@spy 模拟真实对象的部分
说明
在某些情况下，我们需要使用一个真实对象。但是，我们同时需要自定义该对象的部分行为，此时用 @spy 就可以帮我们达到这个目的。
//通过 spy 创建一个可以模拟部分行为的对象，spy()接收的参数是一个真实对象
List list = spy(new LinkedList());
list.add(1);
when(list.get(0)).thenThrow(new Exception());
//如果 get(0)正常执行的话，将会返回 1.但是由于对象经过 spy 并打桩后，它
将抛出异常
list.get(0)；
//与 spy 相反的是，也可以让被 mock 的对象执行真实的行为
Foo mock = mock(Foo.class);
//Be sure the real implementation is 'safe'.
//If real implementation throws exceptions or depends on specific
state of the object then you're in trouble.
when(mock.someMethod()).thenCallRealMethod();示例解析
使用 thenCallRealMethod 时，需要注意真实的实现部分是安全的，否则将会带来麻烦
注意 Mock 和 spy 用法的区别在于：当测试用例中需要使用某个对象的真实方法更多些时，请使用 spy，反之请使用 Mock.
用@InjectMocks 完成依赖注入
说明
类中需要第三方协作者时，通常会用到 get 和 set 方法注入。通过 spring 框架也可以同 @Autowird 等方式完成自动注入。在单元测试中，没有启动 spring 框架，此时就需要通过 InjectMocks 完成依赖注入。InjectMocks 会将带有@Spy 和@Mock 注解的对象尝试注入到被测试的目标类中。
示例
public class ArticleManagerTest extends SampleBaseTestCase {
@Mock
private ArticleCalculator calculator;
@Mock(name = "database")
private ArticleDatabase dbMock;
@Spy
private UserProvider userProvider = new ConsumerUserProvider();
@InjectMocks
private ArticleManager manager;
@Test public void shouldDoSomething() {
manager.initiateArticle();
verify(database).addListener(any(ArticleListener.class));
}
}示例解析
InjectMocks 在注入依赖的对象前，会首先创建一个目标对象的实例。所以，manager 有@ InjectMocks 后，不需要再手动创建实例；
静态模拟方法
说明
与普通方法不同的是，静态方法必须通过其类直接调用。如此，Mockito 中的方法将不再适用于静态方法。此时需要使用 PowerMock.
PowerMock 是一个扩展了其它如 EasyMock 等 mock 框架的、功能更加强大的框架。PowerMock
使用一个自定义类加载器和字节码操作来模拟静态方法，构造函数，final 类和方法，私有方法，去除静态初始化器等等。通过使用自定义的类加载器，简化采用的 IDE 或持续集成服务器不需要做任何改变。熟悉 PowerMock 支持的 mock 框架的开发人员会发现 PowerMock 很容易使用，因为对于静态方法和构造器来说，整个的期望 API 是一样的。PowerMock 旨在用少量的方法和注解扩展现有的 API 来实现额外的功能。目前 PowerMock 支持 EasyMock 和 Mockito。
引入PowerMock 依赖
<powermock-api-mockito.version>1.6.2</powermock-api-mockito.version>
<powermock-module-junit4.version>1.6.2</powermock-module-junit4.version>
<powermock-core.version>1.6.2</powermock-core.version>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-mockito</artifactId>
<version>${powermock-api-mockito.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>${powermock-module-junit4.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-core</artifactId>
<version>${powermock-core.version}</version>
<scope>test</scope>
</dependency示例
//带模拟的静态类
public class FileHelper {
public static boolean isExist() {
return false;
}
}
声明使用powerMock
@RunWith(PowerMockRunner.class)
public class TestClassUnderTest {
@Test
@PrepareForTest(FileHelper.class)
public void testCallStaticMethod() {
ClassUnderTest underTest = new ClassUnderTest();
PowerMockito.mockStatic(FileHelper.class);
PowerMockito.when(FileHelper.isExist()).thenReturn(true);
Assert.assertTrue(underTest.callStaticMethod());
verifyStatic();
FileHelper.isExist()
}
}示例解析
PowerMockRunner 在模拟静态时配置较多，使用时需要注意。另外，静态方法断言时，必须要有 verifyStatic(),然后需要断言的方法紧随其后，如上
Mock 使用时的注意事项
若单个测试用例中（限领域对象）出现了三个及以上的 Mock 对象时，表明被测试的单元与第三方发生了较多的交互，可能违反了单一职责原则。此时，你可能需要暂停测试用例的编写，检查代码设计是否存在设计问题，以保证业务代码和测试用例的可读性。测试用例的编写与重构紧密结合。代码的质量直接影响测试用例的编写，而代码质量的提高依赖于设计和重构。如果发现测试用例编写比较困难，你可能需要重新审视代码设计是否合理
断言
assertEquals
说明 比较两个对象的原始值。如果对象是值类型时，将调用对象的 equals().
示例
assertEqual(expectedResult,actualResult);assertTrue
说明 验证结果是否为 true.
assertTrue(actualResult);assertFalse
说明 验证结果是否为 false.
assertFalse(actualResult);assertNotNull
说明 验证一个结果是否不为 null
assertNotNull(actualResult)assertNull
说明 验证一个结果是否为 null.
assertNull(actualResulassertSame
说明 比较两个对象的引用地址是否相同。
assertSame(expectedResult,actualResult）总结
总原则：先基本后分支，先正常后异常。
用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有
基本流和分支流。由此会产生很多组场景，如下图所示
基本流：经过测试用例最简单的路
分支流：一个分支流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如分支流 1 和 3）；也可能起源于另一个分支流（如分支流 2），或者终止用例而不再重新加入到某个流（如分支流 2 和异常流）
先基本后分支
基本流是业务的基本逻辑，也是业务逻辑的主线。先从基本流入手，一方面有助于抓住业务主线，另一方面在不考虑分支的情况下，先编写基本分支的测试用例，有助于测试用例的逐步深入，保持清晰的层次逻辑。
先正常后异常
先编写正常（正面）的测试用例，即在不发生异常情况下的业务逻辑。正面用例覆盖完全后，再编写异常（负面）的测试用例，用于测试程序对异常的处理情况。正常的测试用例包括正常的基本流和分支流，程序中的异常通常包
- 参数校验错误；
- 数据不符合正常的业务要求；
- 边界错误；
- 数据库操作失败；
- 第三方系统调用异常
正常个人只是为了上线覆盖率，先正常无错误逻辑过一遍，使用powermock进行Dao层的访问是否返回成功。在进行错误的异常抛出，或者if之后的else分支再写一个test。
最后进行断言测试，有时候也不写。毕竟写这玩意费事···
