概述
本文主要介绍单元测试、集成测试相关的概念、技术实现以及最佳实践。
本文的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。 |