基于spring-boot的应用程序的单元+集成测试方案

概述

本文主要介绍单元测试、集成测试相关的概念、技术实现以及最佳实践。

本文的demo是基于Java语言，Spring Boot构建的web应用。测试框架使用Junit，模拟框架使用mockito。

之前曾经总结过一篇文章：基于spring-boot的应用程序的单元测试方案，但是当时只是从技术实现的角度去研究单元测试，很多概念没有搞清楚。本文在重新梳理脉络，丰富概念的基础上，整合了前文的大部分内容，但是有一部分几乎在实践中用不到的内容就被删去了。

在我的个人wiki站点，可以获得更好的阅读体验喔：基于spring-boot的应用程序的单元+集成测试方案

概念解析

单元测试和集成测试

测试领域有很多场景，比如单元测试，集成测试，系统测试，冒烟测试，回归测试，端到端测试，功能测试等。测试的分类方式各有不同，一些测试场景也可能存在重叠。具体这些场景的概念和区别，大家可以阅读文末给出的参考资料。

这里主要以程序员的视角谈一下我理解的单元测试和集成测试。

单元测试是编写单元测试类，针对类级别的测试。比如使用Junit框架，针对一个类，写一个测试类，测试目标类的大部分主要方法。

需要注意单元测试的级别是类。项目当中，类之间的依赖调用是很常见的事，如果你要测试一个类，而这个目标类又调用了另一个类，那么在测试时就没有遵守“在一个类范围内进行测试”，自然算不得单元测试。

如上图所示，假设A，B，C，D四个类之间存在上述的依赖关系，我们要测试类A，那么如何遵守“在类A的范围内测试”？

这就是模拟框架要解决的问题了，通过模拟B和C，我们可以在测试A的时候，调用B和C的模拟对象，而不是实际的B和C。下文会有详细介绍。

如果在测试时超脱一个类的范围，那就可以称为集成测试。如上图所示，你可以测试类A，它会直接或间接调用其他三个类，这就可以叫做集成测试。如果你去测试类C，因为它会调用D，也可以称为集成测试。

如果纯粹按照单元测试的概念，把这个工作代入到一个大型的项目，成百上千的类需要编写测试类，而且类之间的依赖需要编写模拟代码。这样的工作太过庞大，对项目来说应该是得不偿失的。

我推荐的做法是识别核心代码，或者说是重要的代码，只对这些代码做精细的单元测试。除此之外，都通过集成测试来覆盖。集成测试时优先从最顶层开始，让测试自然流下来。然后根据代码测试覆盖报告，再进行补刀。

Mock和Stub

此处介绍的mock和stub，是作者基于mockito框架的理解，行业内对这两个概念的定义和此处的理解可能有所出入。作者不追求对概念有“专业的定义”或者“精确的定义”，如果读者有此追求，可另外查阅其他资料。

上文讲到，在做单元测试的时候，需要屏蔽目标类的依赖，mock和stub就是这种操作涉及到的两个概念。

在项目代码中，经常会涉及依赖多个外部资源的情况，比如数据库、微服务中的其他服务。这表示在测试的时候需要先做很多准备工作，比如准备数据库环境，比如先把依赖的服务run起来。

另外，还需要考虑消除测试的副作用，以使测试具备幂等性。比如如果测试会修改数据库，那么是否会影响二次测试的结果，或者影响整个测试环境？

对外部的资源依赖进行模拟，是一个有效的解决方案。即测试时不是真正的操作外部资源，而是通过自定义的代码进行模拟操作。我们可以对任何的依赖进行模拟，从而使测试的行为不需要任何准备工作或者不具备任何副作用。

在这个大环境下，可以解释mock和stub的含义。当我们在测试时，如果只关心某个操作是否执行过，而不关心这个操作的具体行为，这种技术称为mock。

比如我们测试的代码会执行发送邮件的操作，我们对这个操作进行mock；测试的时候我们只关心是否调用了发送邮件的操作，而不关心邮件是否确实发送出去了。

另一种情况，当我们关心操作的具体行为，或者操作的返回结果的时候，我们通过执行预设的操作来代替目标操作，或者返回预设的结果作为目标操作的返回结果。这种对操作的模拟行为称为stub（打桩）。

比如我们测试代码的异常处理机制是否正常，我们可以对某处代码进行stub，让它抛出异常。再比如我们测试的代码需要向数据库插入一条数据，我们可以对插入数据的代码进行stub，让它始终返回1，表示数据插入成功。

技术实现

单元测试

测试常规的bean

当我们进行单元测试的时候，我们希望在spring容器中只实例化测试目标类的实例。

假设我们的测试目标如下：

@Service
public class CityService {

    @Autowired
    private CityMapper cityMapper;

    public List<City> getAllCities() {
        return cityMapper.selectAllCities();
    }

    public void save(City city) {
        cityMapper.insert(city);
    }
}

我们可以这样编写测试类：

@RunWith(SpringRunner.class)
@SpringBootTest
public class CityServiceUnitTest {

    @SpringBootApplication(scanBasePackages = "com.shouzheng.demo.web")
    static class InnerConfig { }

    @Autowired
    private CityService cityService;

    @MockBean
    private CityMapper cityMapper;

    @Test
    public void testInsert() {
        City city = new City();
        cityMapper.insert(city);
        Mockito.verify(cityMapper).insert(city);
    }

    @Test
    public void getAllCities() {
        City city = new City();
        city.setId(1L);
        city.setName("杭州");
        city.setState("浙江");
        city.setCountry("CN");

        Mockito.when(cityMapper.selectAllCities())
                .thenReturn(Collections.singletonList(city));

        List<City> result = cityService.getAllCities();
        Assertions.assertThat(result.size()).isEqualTo(1);
        Assertions.assertThat(result.get(0).getName()).isEqualTo("杭州");
    }
}

@RunWith注解声明测试是在spring环境下运行的，这样就可以启用Spring的相关支持。

@SpringBootTest注解负责扫描配置来构建测试用的Spring上下文环境。它默认搜索@SpringBootConfiguration类，除非我们通过classes属性指定配置类，或者通过自定义内嵌的@Configuration类来指定配置。如上面的代码，就是通过内嵌类来自定义配置。

@SpringBootApplication扩展自@Configuration，其scanBasePackages属性指定了扫描的根路径。确保测试目标类在这个路径下，而且需要明白这个路径下的所有bean都会被实例化。虽然我们已经尽可能的缩小了实例化的范围，但是我们没有避免其他无关类的实例化开销。

即使如此，这种方案依然被我看作是最佳的实践方案，因为它比较简单。如果我们追求“只实例化目标类”，那么可以使用下面的方式声明内嵌类：

    @Configuration
    @ComponentScan(value = "com.shouzheng.demo.web",
            useDefaultFilters = false,
            includeFilters = @ComponentScan.Filter(
                    type = FilterType.REGEX,
                    pattern = {"com.shouzheng.demo.web.CityService"})
    )
    static class InnerConfig { }

@ComponentScan负责配置扫描Bean的方案，value属性指定扫描的根路径，useDefaultFilters属性取消默认的过滤器，includeFilters属性自定义了一个过滤器，这个过滤器设定为要扫描模式匹配的类。

@ComponentScan默认的过滤器会扫描@Component，@Repository，@Service，@Controller；如果不禁用默认过滤器，自定义过滤器的效果是在默认过滤器的基础上追加更多的bean。即我们要限定只实例化某个特定的bean，就需要把默认的过滤器禁用。

可以看到，这种扫描策略配置，会显得复杂很多。

@Autowired负责注入依赖的bean，在这里注入的是测试目标bean。

@MockBean负责声明这是一个模拟的bean。在进行单元测试时，需要将测试目标的所有依赖bean声明为模拟的bean，这些模拟的bean将被注入测试目标bean。

在testInsert方法中，我们执行了cityMapper.insert，这只是模拟的执行了，实际上什么也没做。接下来我们调用Mockito.verify，目的是验证cityMapper.insert执行了。这正对应了上文中对Mock概念的解释，我们只关心它是否执行了。

需要注意的是，验证的内容同时包括参数是否一致。如果实际调用时的传参和验证时指定的参数不一致，则验证失败，以至于测试失败。

在getAllCities方法中，我们使用Mockito.when对cityMapper.selectAllCities方法进行打桩，设定当方法被调用时，直接返回我们预设的数据。这也对应了上文中对Stub概念的解释。

注意：只能对mock对象进行stub。

测试Controller

Controller是一类特殊的bean，这类bean除了显式的依赖，还有一些系统组件的依赖。比如消息转换组件，负责将方法的返回结果转换成可以写的HTTP消息。所以，我们无法像测试上文那样对其单独实例化。

Spring提供了特定的注解，配置用于测试Controller的上下文环境。

例如我们要测试的controller如下：

@RestController
public class CityController {

    @Autowired
    private CityService cityService;

    @GetMapping("/cities")
    public ResponseEntity<?> getAllCities() {
        List<City> cities = cityService.getAllCities();
        return ResponseEntity.ok(cities);
    }

    @PostMapping("/city")
    public ResponseEntity<?> newCity(@RequestBody City city) {
        cityService.save(city);
        return ResponseEntity.ok(city);
    }

}

我们可以这样编写测试类：

@RunWith(SpringRunner.class)
@WebMvcTest(CityController.class)
public class CityControllerUnitTest {

    @Autowired
    private MockMvc mvc;

    @MockBean
    private CityService service;

    @Test
    public void getAllCities() throws Exception {

        City city = new City();
        city.setId(1L);
        city.setName("杭州");
        city.setState("浙江");
        city.setCountry("中国");

        Mockito.when(service.getAllCities()).
                thenReturn(Collections.singletonList(city));

        mvc.perform(MockMvcRequestBuilders.get("/cities"))
                .andDo(MockMvcResultHandlers.print())
                .andExpect(MockMvcResultMatchers.content().string(Matchers.containsString("杭州")));
    }
}

@WebMvcTest是特定的注解，它的职责和@SpringBootTest相同，但它只会实例化Controller。默认实例化所有的Controller，也可以指定只实例化某一到多个Controller。

除此之外，@WebMvcTest还会实例化一个MockMvc的bean，用于发送http请求。

我们同样需要对测试目标的依赖进行模拟，即，将CityService声明为MockBean。

spring环境问题

@WebMvcTest就像@SpringBootTest一样，默认搜索@SpringBootConfiguration注解的类作为配置类。一般情况下，基于Spring-Boot的web应用，会创建一个启动类，并使用@SpringBootApplication，这个注解可看作@SpringBootConfiguration注解的扩展，所以很可能会搜索到这个启动类作为配置。

如果项目当中有多个@SpringBootConfiguration配置类，比如有些其他的测试类创建了内部配置类，并且使用了这个注解。如果当前测试类没有使用内部类，也没有使用classes属性指定使用哪个配置类，就会因为找到了多个配置类而失败。这种情况下会有明确的错误提示信息。

思考当前测试类会使用哪一个配置类，是一个很好的习惯。

另外一个可能的问题是：如果配置类上添加了其他的注解，比如Mybatis框架的@MapperScan注解，那么Spring会去尝试实例化Mapper实例，但是因为我们使用的是@WebMvcTest注解，Spring不会去实例化Mapper所依赖的sqlSessionFactory等自动配置的组件，最终导致依赖注解失败，无法构建Spring上下文环境。

也就是说，虽然@WebMvcTest默认只实例化Controller组件，但是它同样也会遵从配置类的注解去做更多的工作。如果这些工作依赖于某些自动化配置bean，那么将会出现依赖缺失。

解决这个问题的方法可能有很多种，我这边提供一个自己的最佳实践：

@RunWith(SpringRunner.class)
@WebMvcTest(CityController.class)
public class CityControllerWebLayer {

    @SpringBootApplication(scanBasePackages = {"com.shouzheng.demo.web"})
    static class InnerConfig {}

    @Autowired
    private MockMvc mvc;

    @MockBean
    private CityService service;
}

这个方案，是通过使用内部类来自定义配置。内部类只有一个@SpringBootApplication注解，指定了扫描的根路径，以缩小bean的扫描范围。

测试持久层

就像测试controller一样，持久层的单元测试也有专门的注解支持。

持久层的技术有多种，Spring提供了@JdbcTest来支持通过spring的JdbcTemplate进行持久化的测试，提供了@DataJpsTest支持通过JPA技术进行持久化的测试。

上面的这两个注解我没有做过研究，因为项目中使用的是Mybatis，这里仅介绍Mybatis提供的测试支持：@MybatisTest。

最简单的方式是使用内存数据库作为测试数据库，这样可以尽量减少测试的环境依赖。

默认的持久层测试是回滚的，即每一个测试方法执行完成之后，会回滚对数据库的修改；所以也可以使用外部的数据库进行测试，但多少会有些影响（比如序列的当前值）。

使用内存数据库

首先，添加数据库依赖：

<!-- pom.xml -->
<dependency>
	<groupId>com.h2database</groupId>
	<artifactId>h2</artifactId>
	<version>RELEASE</version>
	<scope>test</scope>
</dependency>

准备数据库初始化脚本，比如放在resources/import.sql文件中：

drop table if exists city;
drop table if exists hotel;

create table city (id int primary key AUTO_INCREMENT, name varchar, state varchar, country varchar);
create table hotel (city int primary key AUTO_INCREMENT, name varchar, address varchar, zip varchar);

insert into city (id, name, state, country) values (1, 'San Francisco', 'CA', 'US');
insert into hotel(city, name, address, zip) values (1, 'Conrad Treasury Place', 'William & George Streets', '4001')

需要在配置文件中指定脚本文件的位置：

spring.datasource.schema=classpath:import.sql

例如我们要测试如下的Mapper接口：

@Mapper
public interface CityMapper {

    City selectCityById(int id);

    List<City> selectAllCities();

    int insert(City city);

}

我们可以这样编写测试类：

@RunWith(SpringRunner.class)
@MybatisTest
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class CityMapperUnitTest {

    @SpringBootApplication(scanBasePackages = {"com.shouzheng.demo.mapper"})
    static class InnerConfig {}

    private static Logger LOG = LoggerFactory.getLogger(CityMapperUnitTest.class);

    @Autowired
    private CityMapper cityMapper;

    @Before
    @After
    public void printAllCities() {
        List<City> cities = cityMapper.selectAllCities();
        LOG.info("{}", cities);
    }

    @Test
//    @Rollback(false) // 禁止回滚
    public void test1_insert() throws Exception {
        City city = new City();
        city.setName("杭州");
        city.setState("浙江");
        city.setCountry("CN");
        cityMapper.insert(city);
        LOG.info("insert a city {}", city);
    }

    @Test
    public void test2_doNothing() {
    }
}

@MybatisTest搜索配置类的逻辑和@SpringBootTest、@WebMvcTest相同，为了避免Spring环境问题（上文在测试Controller一节中介绍过），这里直接使用内部类进行配置。

@FixMethodOrder(MethodSorters.NAME_ASCENDING)用来指定测试方法的执行顺序，这是为了观察事务回滚的效果。

如果将test1_insert方法上的@Rollback(false)注释放开，事务不会回滚，test2_doNothing方法之后打印输出的内容会包含test1_insert方法里插入的数据。

反之，如果注释掉，事务回滚，test2_doNothing方法之后打印输出的内容不包含test1_insert方法里插入的数据。

使用外部数据库

首先，添加对应的数据库驱动依赖，以及数据源配置。比如使用mysql外部数据库：

<!-- pom.xml -->
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>${mysql-jdbc.version}</version>
</dependency>

# application.yml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/test?autoReconnect=true&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull&transformedBitIsBoolean=true&useSSL=false
    username: root
    password: root
    driver-class-name: com.mysql.jdbc.Driver

然后配置测试类，唯一不同的是，在测试类上要多加一个@AutoConfigureTestDatabase注解：

@RunWith(SpringRunner.class)
@MybatisTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
public class CityMapperTest2 {

    @SpringBootApplication(scanBasePackages = {"com.shouzheng.demo.mapper"})
    static class InnerConfig {}
    
    @Autowired
    private CityMapper cityMapper;
    
    // ...
}

这样，测试的时候就会使用我们配置的数据库进行测试，而不是使用内存数据库。

事务回滚设置

测试持久层时，默认是回滚的。可以在具体的测试方法上添加@Rollback(false)来禁止回滚，也可以在测试类上添加。

集成测试

集成测试时会超脱一个类的范围，我们需要保证自测试目标类及以下的依赖类，都能够在spring容器中被实例化，最简单的方式莫过于构建完整的spring上下文。虽然这样一来，会有很多和测试目标无关的类也会被实例化，但是我们省去了精心设计初始化bean的工夫，而且也间接的达到了“测试构建完整的spring上下文”的目的。

从Controller开始测试

例如我们以上文中介绍到的controller为测试目标，测试newCity请求。测试类如下：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = DemoTestSpringBootApplication.class)
@AutoConfigureMockMvc
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class CityControllerWithRollbackTest {

    private static Logger LOG = LoggerFactory.getLogger(CityControllerWithRollbackTest.class);

    @Autowired
    private MockMvc mockMvc;

    @Before
    @After
    public void getAllCities() throws Exception {
        mockMvc.perform(MockMvcRequestBuilders.get("/cities"))
                .andDo(result -> {
                    String content = result.getResponse().getContentAsString();
                    LOG.info("cities = {}", content);
                });
    }

    @Test
    @Transactional
//    @Rollback(false)
    public void test1_insertCity() throws Exception {

        LOG.info("insert a city");

        mockMvc.perform(MockMvcRequestBuilders.post("/city")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"name\": \"杭州\", \"state\": \"浙江\", \"country\": \"中国\"}"))
                .andExpect(MockMvcResultMatchers.status().isOk());
    }

    /**
     * 为了观察数据库是否回滚
     */
    @Test
    public void test2_doNothind() {

    }

}

这段代码主要测试新增数据记录的请求，并在测试前后分别请求并打印当前的数据记录集。我们可以看到，在test1_insertCity方法运行之后打印的数据集，会比在此之前打印的数据集多一条记录，而这条记录正是我们申请新增的数据记录。

test2_doNothind是一个辅助的测试方法，在完成test1_insertCity方法之后，开始执行test2_doNothind测试。而测试前的打印数据记录集的行为，可以让我们观察到test1_insertCity测试中新增的数据是否发生回滚。

集成测试时使用@SpringBootTest注解，指定配置类为项目启动类。如果我们的项目是基于spring-cloud的微服务环境，那么也可以使用内部配置类来减少服务注册等相关的配置。

@AutoConfigureMockMvc是为了实例化MockMvc实例，用来发送http请求。

事务回滚设置

实验证明，集成测试依然可以支持数据库操作回滚，方案就是在测试方法上使用@Transactional注解，标识事务性操作。同时，我们依然可以使用@Rollback来设置是否回滚。

从中间层开始测试

集成测试不是非要从最顶层开始测试，我们也可以从service层开始测试：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {DemoTestSpringBootApplication.class})
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class CityServiceWithRollbackTest {

    private static Logger LOG = LoggerFactory.getLogger(CityServiceWithRollbackTest.class);

    @Autowired
    private CityService cityService;

    @Before
    @After
    public void printAllCities() {
        List<City> cities = cityService.getAllCities();
        LOG.info("{}", cities);
    }

    @Test
    @Transactional
    public void test1_insert() {
        City city = new City();
        city.setName("杭州");
        city.setState("浙江");
        city.setCountry("CN");

        cityService.save(city);
        LOG.info("insert a new city {}", city);
    }

    @Test
    public void test2_doNothind() {

    }

}

这段代码的测试方案和上文的controller集成测试方案相同，都是测试新增操作，并在测试前后打印当前数据集，来演示是否支持事务回滚。

Mock

在spring项目的测试类中，我们可以对任意的类进行mock，如下面这样：

@RunWith(SpringRunner.class)
@SpringBootTest
public class CityServiceUnitTest {

    @MockBean
    private CityMapper cityMapper;

    ...
}

定义一个field，对其添加@MockBean注解，就声明了对应类型的一个mock bean。如果spring上下文中已经存在对应类型的bean，将会被mock bean覆盖掉。

默认的情况下，mock bean的所有方法都是透明的：什么也不做，直接返回对应类型的默认值。声明返回引用类型的方法，将直接返回null；声明返回基本类型的方法，直接返回相应的默认值；声明无返回的方法，那更是透明的。

mock的作用对静态方法无效，静态方法会被实际调用。所以建议不要在静态方法中进行资源相关的处理，否则将无法进行模拟测试。比如，使用静态方法封装数据库操作的行为是不好的。

如上文所述，Mock的使用场景是我们只关注对应的方法是否执行了，而不关心实际的执行效果。实际代码中，我们可以按照下面的方式使用：

    @Test
    @Transactional
    public void test1_insert() {
        City city = new City();
        city.setName("杭州");
        city.setState("浙江");
        city.setCountry("CN");

        cityService.save(city);
        Mockito.verify(cityMapper).insert(city);
        LOG.info("insert a new city {}", city);
    }

Mockito.verify开始的一行，用来验证作为mock bean的cityMapper的insert方法会被执行，而且参数为city。如果方法没有被调用，或者实际调用时的传参不一致，都会导致测试失败。

比如，如果改成Mockito.verify(cityMapper).insert(new City());，将会抛出下面的异常：

Argument(s) are different! Wanted:
cityMapper bean.insert(null,null,null,null);
-> at com.shouzheng.demo.web.CityServiceWithRollbackTest.test1_insert(CityServiceWithRollbackTest.java:56)
Actual invocation has different arguments:
cityMapper bean.insert(null,杭州,浙江,CN);
-> at com.shouzheng.demo.web.CityService.save(CityService.java:26)

Comparison Failure: 
Expected :cityMapper bean.insert(null,null,null,null);
Actual   :cityMapper bean.insert(null,杭州,浙江,CN);

Stub

在Mock的基础上更进一步，如果我们关注方法的返回结果，或者我们希望方法能有预定的行为，使得测试按照我们预期的方向进行，那么我们需要对mock bean的某些方法进行stub，让这些方法在参数满足某个条件的情况下，给我们预设的响应。

实际代码中，我们只能对mock bean的方法进行stub，否则得到下面的异常：

org.mockito.exceptions.misusing.MissingMethodInvocationException: 
when() requires an argument which has to be 'a method call on a mock'.
For example:
    when(mock.getArticles()).thenReturn(articles);

Also, this error might show up because:
1. you stub either of: final/private/equals()/hashCode() methods.
   Those methods *cannot* be stubbed/verified.
   Mocking methods declared on non-public parent classes is not supported.
2. inside when() you don't call method on mock but on some other object.

返回预设的结果

我们可以按照下面的方式，让它返回预设的结果：

Mockito.when(cityMapper.selectAllCities())
        .thenReturn(Collections.singletonList(city));

或者抛出预设的异常（如果我们检测异常处理代码的话）：

Mockito.when(cityMapper.selectAllCities())
        .thenThrow(new RuntimeException("test"));

或者去执行实际的方法：

when(mock.someMethod()).thenCallRealMethod();

注意，调用真实的方法有违mock的本义，应该尽量避免。如果要调用的方法中调用了其他的依赖，需要自行注入其他的依赖，否则会空指针。

执行预设的操作

如果我们希望它能够执行预设的操作，比如打印我们传入的参数，或者修改我们传入的参数，我们可以按照下面的方式实现：

Mockito.when(cityMapper.insert(Mockito.any()))
        .then(invocation -> {
            LOG.info("arguments are {}", invocation.getArguments());
            return 1;
        });

参数匹配

我们可以指定明确的参数匹配条件，或者使用模式匹配：

@RunWith(SpringRunner.class)
@SpringBootTest
public class MathServiceTest {

    @Configuration
    static class ConfigTest {}

    @MockBean
    private MathService mathService;

    @Test
    public void testDivide() {
        Mockito.when(mathService.divide(4, 2))
                .thenReturn(2);

        Mockito.when(mathService.divide(8, 2))
                .thenReturn(4);

        Mockito.when(mathService.divide(Mockito.anyInt(), Mockito.eq(0))) // 必须同时用模式
                .thenThrow(new RuntimeException("error"));

        Assertions.assertThat(mathService.divide(4, 2))
                .isEqualTo(2);

        Assertions.assertThat(mathService.divide(8, 2))
                .isEqualTo(4);

        Assertions.assertThatExceptionOfType(RuntimeException.class)
                .isThrownBy(() -> {
                    mathService.divide(3, 0);
                })
                .withMessageContaining("error");
    }
}

上面的测试可能有些奇怪，mock的对象也同时作为测试的目标。这是因为我们的目的在于介绍mock，所以简化了测试流程。

注意，如果我们对方法的其中一个参数使用了模式，其他的参数都需要使用模式。比如下面这句：

Mockito.when(mathService.divide(Mockito.anyInt(), Mockito.eq(0)))，我们的本意是Mockito.when(mathService.divide(Mockito.anyInt(), 0))，但是我们不得不为第二个参数使用模式。

附录

注解	说明
`@RunWith`	junit的注解，通过这个注解使用`SpringRunner.class`，能够将junit和spring进行集成。后续的spring相关注解才会起效。
`@SpringBootTest`	spring的注解，通过扫描应用程序中的配置来构建测试用的Spring上下文。
`@AutoConfigureMockMvc`	spring的注解，能够自动配置`MockMvc`对象实例，用来在模拟测试环境中发送http请求。
`@WebMvcTest`	spring的注解，切片测试的一种。使之替换`@SpringBootTest`能将构建bean的范围限定于web层，但是web层的下层依赖bean，需要通过mock来模拟。也可以通过参数指定只实例化web层的某一个到多个controller。具体可参考Auto-configured Spring MVC Tests。
`@RestClientTest`	spring的注解，切片测试的一种。如果应用程序作为客户端访问其他Rest服务，可以通过这个注解来测试客户端的功能。具体参考Auto-configured REST Clients。
`@MybatisTest`	mybatis按照spring的习惯开发的注解，切片测试的一种。使之替换`@SpringBootTest`，能够将构建bean的返回限定于mybatis-mapper层。具体可参考mybatis-spring-boot-test-autoconfigure。
`@JdbcTest`	spring的注解，切片测试的一种。如果应用程序中使用Jdbc作为持久层（spring的`JdbcTemplate`），那么可以使用该注解代替`@SpringBootTest`，限定bean的构建范围。官方参考资料有限，可自行网上查找资料。
`@DataJpaTest`	spring的注解，切片测试的一种。如果使用Jpa作为持久层技术，可以使用这个注解，参考Auto-configured Data JPA Tests。
`@DataRedisTest`	spring的注解，切片测试的一种。具体内容参考Auto-configured Data Redis Tests。

参考资料

Spring Boot Testing

Spring Boot Test博客

Mybatis Spring Boot Test官方资料

深入探討 Test Double、Dummy、Fake、Stub 、Mock 與 Spy

单元测试，集成测试概念与各种工具介绍

posted on 2018-11-21 19:55 一尾金鱼阅读(5115) 评论(1) 编辑收藏举报

基于spring-boot的应用程序的单元+集成测试方案

概述

概念解析

单元测试和集成测试

Mock和Stub

技术实现

单元测试

测试常规的bean

测试Controller

测试持久层

使用内存数据库

使用外部数据库

事务回滚设置

集成测试

从Controller开始测试

事务回滚设置

从中间层开始测试

Mock

Stub

返回预设的结果

执行预设的操作

参数匹配

附录

相关注解的汇总

参考资料