Mock框架的三次迭代，让你的单元测试更高效

如何定义单元

对于单元测试中的单元，不同的人有不同的看法：可以理解为一个方法，可以理解为一个完整的接口实现，也可以理解为一个完整的功能模块或者是多个功能模块的一个耦合。

根据以往的单元测试经验，在设计单元测试用例时，当针对方法级别展开单元测试时，重点关注的是方法的底层逻辑;当针对的是模块时，针对的是实际的业务逻辑实现;当针对整合后的模块进行测试时，一般称之为集成测试。

不管是单元测试还是集成测试，都可以统一的理解为单元测试。因为他们的本质都是对方法或接口的一种测试形式，只是所处的阶段不一样罢了。

1. 集成测试应该由谁编写

在我们的实际工作中，研发人员在提交代码之前，会设计一些“冒烟测试”级别集成测试用例。等到整个功能开发完成后，测试人员会根据业务需求和设计的测试用例，来进行整体的集成测试用例的编写、执行、失败用例分析，以及代码的调式和问题代码的定位等工作。

2. 集成测试用例

业务相关的测试主要是通过spring-test来进行集成测试，基本的测试结构为先定义一个基类用来初始化被测试类。

测试基类定义结构如下：

@RunWith(SpringJUnit4ClassRunner.class)   

ContextConfiguration(locations = {"classpath:./spring/applicationContext.xml"})   

@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS)   

public class BaseSpringJunitTest {   

    @Autowired   

    protected BusinessRelatedServiceImpl businessRelatedService;   

} 

业务相关的测试类定义如下格式：

  public class BusinessRelatedServiceImplDomainTest  extends BaseSpringJunitTest {  

  @Test   

  public void testScenario1 (){  

  new Thread(new DOSAutoTest("testScenario1")).start();   

  Thread.sleep(1000*60*1);   

  String requestJson=""//测试入参;   

  RequestPojo request=( RequestPojo )JSONUtils.jsonToBean(requestJson,RequestPojo .class);   

  ResponsePojo response= businessRelatedService.businessRelatedMethod(ResponsePojo );   

  //业务相关的assert区域   

}   

} 

3. 如何解决下游系统依赖

businessRelatedMethod方法在处理业务逻辑的过程中需要调用下游JSF(Jingdong Service Framework，完全自主研发的高性能RPC服务框架)提供的订单接口(OrderverExportService)，并根据入参中的订单编号获取订单的详细信息(ResultPojo getOrderInfoById (long orderId))。

那么如何获取下游JSF接口的返回正确数据就变成了一个比较重要的问题。如果是在功能测试或者联调测试阶段，可以由下游测试人员来提供数据。不过这样沟通和测试成本较高，无法满足业务快速上线和变化的要求，尤其在集成测试阶段这个问题就变得尤为明显，因为下游数据对于上游来说是不可控的。这样mock下游数据就变得尤为紧急和重要。

4. Mock框架的选择

在整个java生态圈中，支持mock的开源框架还是比较多的，比如常用的mockito、powermock、easymock和jmockit等开源框架。这些框架在mock方面都具有比较强大的功能与比较广泛的使用量。但是这些框架都具有一个相同的缺点，那就是需要或多或少的编码工作来mock所需要的接口返回数据。

在设计mock框架的时候，我们考虑到尽量让写单元测试的人员或研发人员少编码或不编码，来获取不同的业务场景所需要的测试数据。

Mock框架 第一版