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

作者: heyikan | 来源:发表于2018-11-21 19:38 被阅读73次

概述

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

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

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

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

概念解析

单元测试和集成测试

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

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

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

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

1.jpg

如上图所示，假设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

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

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

概述

概念解析

单元测试和集成测试

Mock和Stub

技术实现

单元测试

测试常规的bean

测试Controller

测试持久层

使用内存数据库

使用外部数据库

事务回滚设置

集成测试

从Controller开始测试

事务回滚设置

从中间层开始测试

Mock

Stub

返回预设的结果

执行预设的操作

参数匹配

附录

相关注解的汇总

参考资料

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

自动化测试

程序员

Spring cloud