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

概述

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

本文的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.whencityMapper.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)),但是我们不得不为第二个参数使用模式。

附录

相关注解的汇总

2.png
注解 说明
@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

参考资料

推荐阅读更多精彩内容