丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
资深技术专家手把手带教
技术交流，直击现场
让创作激发创新
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
高德的技术大佬向老师在谈论方法论时说到：“复杂的问题要简单化，简单的问题要深入化。”这句话让我感触颇深，这何尝不是一套编写代码的方法——把一个复杂逻辑拆分为许多简单逻辑，然后把每一个简单逻辑进行深入实现，最后把这些简单逻辑整合为复杂逻辑，总结为八字真言即是“化繁为简，由简入繁”。编写Java单元测试用例，其实就是把“复杂的问题要简单化”——即把一段复杂的代码拆解成一系列简单的单元测试用例；写好Java单元测试用例，其实就是把“简单的问题要深入化”——即学习一套方法、总结一套模式并应用到实践中。这里，作者根据日常的工作经验，总结了一些Java单元测试技巧，以供大家交流和学习。
PowerMock是一个扩展了其它如EasyMock等mock框架的、功能更加强大的框架。PowerMock使用一个自定义类加载器和字节码操作来模拟静态方法、构造方法、final类和方法、私有方法、去除静态初始化器等等。
这里，用List举例，模拟一个不存在的列表，但是返回的列表大小为100。
两种模式都用于模拟对象方法，在mock实例下使用时，基本上是没有差别的。但是，在spy实例下使用时，when().thenReturn()模式会执行原方法，而doReturn().when()模式不会执行原方法。测试服务类：
使用when().thenReturn()模式：
在测试过程中，将会打印出"调用获取用户数量方法"日志。
使用doReturn().when()模式：
在测试过程中，不会打印出"调用获取用户数量方法"日志。
4.4. whenNew模拟构造方法
在执行单元测试时，有时候并不关心传入的参数的值，可以使用参数匹配器。
Mockito的AdditionalMatchers类提供了一些很少使用的参数匹配器，我们可以进行参数大于(gt)、小于(lt)、大于等于(geq)、小于等于(leq)等比较操作，也可以进行参数与(and)、或(or)、非(not)等逻辑计算等。
验证是确认在模拟过程中，被测试方法是否已按预期方式与其任何依赖方法进行了交互。
格式：
用途：
用于模拟对象方法，直接返回期望的值、异常、应答，或调用真实的方法，无需执行原始方法。
案例：
除times外，Mockito还支持atLeastOnce、atLeast、only、atMostOnce、atMost等次数验证器。
Mockito没有静态方法的验证方法，但是PowerMock提供这方面的支持。
通过模拟方法stub(存根)，也可以实现模拟私有方法。但是，只能模拟整个方法的返回值，而不能模拟指定参数的返回值。
这里，也可以用Method那套方法进行模拟和验证方法。
PowerMock为了更好地支持SpringMVC/SpringBoot项目，提供了一系列的注解，大大地简化了测试代码。
指定JUnit 使用 PowerMock 框架中的单元测试运行器。
当需要模拟final类、final方法或静态方法时，需要添加@PrepareForTest注解，并指定方法所在的类。如果需要指定多个类，在{}中添加多个类并用逗号隔开即可。
@Mock注解创建了一个全部Mock的实例，所有属性和方法全被置空（0或者null）。
@Spy注解创建了一个没有Mock的实例，所有成员方法都会按照原方法的逻辑执行，直到被Mock返回某个具体的值为止。
注意：@Spy注解的变量需要被初始化，否则执行时会抛出异常。
@InjectMocks注解创建一个实例，这个实例可以调用真实代码的方法，其余用@Mock或@Spy注解创建的实例将被注入到用该实例中。
为了解决使用PowerMock后，提示ClassLoader错误。
【强制】好的单元测试必须遵守AIR原则。 说明：单元测试在线上运行时，感觉像空气（AIR）一样感觉不到，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。
A：Automatic（自动化）
I：Independent（独立性）
R：Repeatable（可重复）
【强制】单元测试是可以重复执行的，不能受到外界环境的影响。
说明：单元测试通常会被放到持续集成中，每次有代码check in时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。
正例：为了不受外界环境影响，要求设计代码时就把SUT的依赖改成注入，在测试时用spring 这样的DI框架注入一个本地（内存）实现或者Mock实现。
【推荐】编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量。
C：Correct，正确的输入，并得到预期的结果。
D：Design，与设计文档相结合，来编写单元测试。
E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。
Mock可以用来解除外部服务依赖，从而保证了测试用例的独立性。
现在的互联网软件系统，通常采用了分布式部署的微服务，为了单元测试某一服务而准备其它服务，存在极大的依耐性和不可行性。
Mock可以减少全链路测试数据准备，从而提高了编写测试用例的速度。
传统的集成测试，需要准备全链路的测试数据，可能某些环节并不是你所熟悉的。最后，耗费了大量的时间和经历，并不一定得到你想要的结果。现在的单元测试，只需要模拟上游的输入数据，并验证给下游的输出数据，编写测试用例并进行测试的速度可以提高很多倍。
Mock可以模拟一些非正常的流程，从而保证了测试用例的代码覆盖率。
根据单元测试的BCDE原则，需要进行边界值测试（Border）和强制错误信息输入（Error），这样有助于覆盖整个代码逻辑。在实际系统中，很难去构造这些边界值，也能难去触发这些错误信息。而Mock从根本上解决了这个问题：想要什么样的边界值，只需要进行Mock；想要什么样的错误信息，也只需要进行Mock。
Mock可以不用加载项目环境配置，从而保证了测试用例的执行速度。
在进行集成测试时，我们需要加载项目的所有环境配置，启动项目依赖的所有服务接口。往往执行一个测试用例，需要几分钟乃至几十分钟。采用Mock实现的测试用例，不用加载项目环境配置，也不依赖其它服务接口，执行速度往往在几秒之内，大大地提高了单元测试的执行速度。
在实际工作中，不少同学用集成测试代替了单元测试，或者认为集成测试就是单元测试。这里，总结为了单元测试与集成测试的区别：
测试对象不同单元测试对象是实现了具体功能的程序单元，集成测试对象是概要设计规划中的模块及模块间的组合。
测试方法不同单元测试中的主要方法是基于代码的白盒测试，集成测试中主要使用基于功能的黑盒测试。
测试内容不同单元测试主要是模块内程序的逻辑、功能、参数传递、变量引用、出错处理及需求和设计中具体要求方面的测试；而集成测试主要验证各个接口、接口之间的数据传递关系，及模块组合后能否达到预期效果。
关注阿里云公众号或下载阿里云APP，关注云资讯，随时随地运维管控云服务