Spring Boot 应用的测试Spring Boot 应用的测试

Spring Boot 应用的测试

《Spring Boot 实战开发》(陈光剑) —— 基于 Gradle + Kotlin的企业级应用开发最佳实践

本书写到这里，Spring Boot 2.0.0.RC1版本已经于2018.1.31 发布。这是本书最后一章，本章介绍 Spring Boot 应用的测试（质量保障）相关的内容。我们在项目开发中使用分层架构，在测试中也进行分层测试。 1.1 准备工作 本节先来创建一个基于Spring MVC、 Spring Data JPA的 Spring Boot， 完成Dao 层、 Service 层、Controller 层代码的编写，为后面的测试代码的编写做准备。 使用http://start.spring.io/ 创建项目、导入此 Gradle 项目到 IDEA 中。配置 Kotlin Compiler 版本与Target JVM 版本。最后等待项目构建完毕。我们将得到一个初始Spring Boot 工程。详细的代码参考本章给出的示例工程源码。 下面我们来详细讲解怎样针对 Spring Boot 项目进行分层测试。 1.2 分层测试 我们在开发阶段过程中，单元测试通常是必要的。Spring Boot 提供的spring-boot-test 模块基于 spring-test 模块和junit 框架，封装集成了功能强大的结果匹配校验器assertj 、hamcrest Matcher、 Web 请求 Mock 对象、 httpclient、JsonPath （测试 JSON 数据）、mockito、selenium等。 测试代码通常放在 src/test 目录下，包目录规范是跟 src/main 目录保持一致。测试代码目录结构设计如下

图15-1 测试代码目录结构 测试代码的分层逻辑与项目源代码中的 dao层、service 层、controller 层各自对应。 下面我们来开发具体的测试类。 1.2.1 Dao 层测试 在包com.easy.springboot.demo_testing_and_deploy.dao下面添加UserDaoTest.kt测试类，代码如下

@RunWith(SpringRunner::class)
@SpringBootTest
class UserDaoTest {
    @Autowired lateinit var userDao: UserDao
    @Test
    fun testFindAll() {
        Assert.assertTrue(userDao.findAll().size == 2)
    }
}

其中，需要测试类上需要添加@RunWith(SpringRunner.class) 和 @SpringBootTest 注解。这里的 @RunWith这里就不多做解释了，在 JUnit中这个是最常用的注解。 @SpringBootTest这个注解是SpringBoot项目测试的核心注解，标识该测试类以SpringBoot方式运行，该注解的定义如下：

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@BootstrapWith(SpringBootTestContextBootstrapper.class)
public @interface SpringBootTest{}

在上面的 @SpringBootTest 注解源码中最重要的是 @BootstrapWith，该注解配置了测试类的启动核心类SpringBootTestContextBootstrapper。 在UserDaoTest测试类中可以直接使用@Autowired来装配UserDao这个 Bean。而且，@SpringBootTest 注解会自动帮我们完成启动一个 Spring 容器 ApplicationContext，然后连接数据库，执行一套完整的业务逻辑。 1.2.2 Service 层测试 Service 层的代码测试类跟 Dao 层类似，例如UserServiceTest.kt 测试代码如下

@RunWith(SpringRunner::class)
@SpringBootTest
class UserServiceTest {
    // 直接使用@Autowired注解注入 Service 对象
    @Autowired lateinit var userService: UserService

    @Test
    fun testFindAll() {
        Assert.assertTrue(userService.findAll().size == 2)
    }
}

1.2.3 使用 Mockito 测试 Service 层代码

上面的测试代码是连接真实的数据库来执行真实的 Dao 层数据库查询逻辑。 而在实际开发的场景中，我们有时候需要独立于数据库进行 Service 层逻辑的开发。这个时候就可以直接把数据库Dao层代码Mock 掉。例如在UserService中有一个 getOne()方法，具体的实现代码是

interface UserService {
    ...
    fun getOne(id:Long):User?
}

@Service
class UserServiceImpl : UserService {
    @Autowired lateinit var userDao: UserDao
    ...

    override fun getOne(id: Long): User? {
        return userDao.getOne(id)
    }
}

下面，我们就使用 Mockito 来把 UserDao 层代码 Mock 掉。Mockito 主要用于 service 层的 mock 测试。mock 的对象一般是对 DAO 层的依赖； 另外就是别人的Service实现类。 新建测试类MockUserServiceTest.kt 代码如下：

@RunWith(MockitoJUnitRunner::class)
class MockUserServiceTest {
    @Mock
    lateinit var mockUserDao: UserDao // mock 一个DAO层的接口
    @InjectMocks
    lateinit var userService: UserServiceImpl// Mock一个 Service 的实现类，用 @InjectMocks。注意这里是实现类 UserServiceImpl

    @Before
    fun setUp() {
        // initMocks 必须,否则 @Mock 注解无效
        MockitoAnnotations.initMocks(this)
    }

    @Test
    fun testGetOne() {
        val mockUser = User()
        mockUser.id = 101
        mockUser.username = "mockUser"
        mockUser.password = "123456"

        val roles = mutableSetOf<Role>()
        val r1 = Role()
        r1.role = "ROLE_USER"
        val r2 = Role()
        r1.role = "ROLE_ADMIN"
        roles.add(r1)
        roles.add(r2)
        mockUser.roles = roles
        //模拟 UserDao对象
        `when`(mockUserDao.getOne(1)).thenReturn(mockUser)

        val u = userService.getOne(1)
        println(ObjectMapper().writeValueAsString(u))
        Assert.assertTrue(u?.password == "123456")
    }
}

需要注意的是，该测试的执行 Runner 是 @RunWith(MockitoJUnitRunner::class) 。  使用 @Mock 注解标记这个对象是被 Mock 的。  使用 @InjectMocks 注解标注一个实现类UserServiceImpl，Mockito 会自动把 @Spy 或 @Mock标注的 Mock 对象注入到实现类UserServiceImpl的方法执行中，相当于把实现类中的UserDao对象使用mockUserDao对象给“偷梁换柱”了。 运行上面的测试类，可以发现测试成功

图15-2 MockUserServiceTest测试成功 在测试代码的打印日志中，输出的 getOne(1)方法的返回对象是我们 Mock 的对象mockUser ：

{"id":101,"gmtCreate":"2018-02-09 01:48:33","gmtModify":"2018-02-09 01:48:33","username":"mockUser","password":"123456","roles":[{"id":-1,"gmtCreate":"2018-02-09 01:48:33","gmtModify":"2018-02-09 01:48:33","role":"ROLE_ADMIN"},{"id":-1,"gmtCreate":"2018-02-09 01:48:33","gmtModify":"2018-02-09 01:48:33","role":"ROLE_USER"}]}

提示：更多关于 Mockito 的使用请参考官网文档：http://site.mockito.org/

1.2.4 Controller 层测试 通过上面的实例，我们已经了解了在实际项目开发测试中对dao层代码和service层代码的测试，还学习了 Mockito 技术的相关内容。spring-boot-starter-test中提供了对项目测试功能的强大支持，更难得的是其中增加了对Controller层测试的支持。 下面我们来测试接口 http://127.0.0.1:8012/user/1 。该接口的输出的JSON数据如下

{
  "id": 1,
  "gmtCreate": "2018-02-08 12:58:14",
  "gmtModify": "2018-02-08 12:58:14",
  "username": "user",
  "password": "user",
  "roles": [
    {
      "id": 1,
      "gmtCreate": "2018-02-08 12:58:14",
      "gmtModify": "2018-02-08 12:58:14",
      "role": "ROLE_USER"
    }
  ]
}

UserControllerTest测试代码如下

@RunWith(SpringJUnit4ClassRunner::class)
@SpringBootTest
class UserControllerTest {

    @Autowired
    lateinit var context: WebApplicationContext
    lateinit var mvc: MockMvc
    @Before
    fun setUp() {
        mvc = MockMvcBuilders.webAppContextSetup(context).build()
    }

    @Test
    fun testFetchUser1() {
        mvc.perform(MockMvcRequestBuilders.get("/user/1")
                .contentType(MediaType.APPLICATION_JSON_UTF8)
                .accept(MediaType.APPLICATION_JSON))
                .andExpect(MockMvcResultMatchers.status().isOk)
                .andDo(MockMvcResultHandlers.print())
                .andExpect(MockMvcResultMatchers.content().string(Matchers.containsString("""
                    "username":"user"
                """.trimIndent())))
                .andDo {
                    println("it.request.method=${it.request.method}")
                    println("it.response.contentAsString=${it.response.contentAsString}")
                }
                .andExpect(MockMvcResultMatchers.jsonPath("$.id", Matchers.equalTo(1)))
                .andExpect(MockMvcResultMatchers.jsonPath("$.roles[0].role", Matchers.equalTo("ROLE_USER")))

    }
}

其中， MockMvc是一个被final修饰的类型，该类无法被继承使用。这个类在包org.springframework.test.web.servlet下面，是Spring提供的模拟SpringMVC请求的实例类，该类由MockMvcBuilders通过WebApplicationContext实例进行创建。MockMvcBuilder接口签名如下

package org.springframework.test.web.servlet;
public interface MockMvcBuilder {
  MockMvc build();
}

上面的代码简单说明如下表15-1。 表15-1 方法名 功能说明 Perform() 方法其实只是为了构建一个请求，并且返回ResultActions实例，使用该实例可以获取到请求的返回内容。

MockMvcRequestBuilders 支持构建多种请求方法对象，如：Post、Get、Put、Delete等常用的请求方式，其中的参数"/user/1"则是我们需要请求的本项目的相对路径，/ 则是项目请求的根路径。另外，还可以调用param() 方法用于在发送请求时携带参数。

andExpect() 是ResultActions中成员，入参是ResultMatcher类型： ResultActions andExpect(ResultMatcher matcher) 在发送请求后对响应结果进行匹配校验时调用。其中MockMvcResultMatchers 抽象类是一个静态工厂，用于生产ResultMatcher对象。MockMvcResultMatchers中提供了丰富的匹配器。

1.2.5 JSON接口测试 使用 JsonPath 我们可以像 JavaScript 语法一样方便地进行 JSON 数据返回的访问操作。例如下面的这两行代码 .andExpect(MockMvcResultMatchers.jsonPath("$.id", Matchers.equalTo(1))) .andExpect(MockMvcResultMatchers.jsonPath("$.roles[0].role", Matchers.equalTo("ROLE_USER"))) 这里的Matchers类是org.hamcrest包下面的类。org.hamcrest.Matchers 类中提供了丰富的断言方法，这些方法的具体使用可以阅读Matchers 类的源码深入了解。 其中，"$.id" 和 "$.roles[0].role" 就是 JsonPath的表达式语法。 提示：更多关于 JsonPath 的内容可以参考： https://github.com/json-path/JsonPath 。

运行上面的测试代码，测试成功：

图15-3 UserControllerTest测试成功 使用命令 $ gradle test 可以一次性全部执行 src/test 目录下面的测试类。在 IDEA 中可以直接邮寄 src/test 目录，选择 Run > All Tests执行所有测试类，如下图所示

图15-4 选择 Run > All Tests执行 所有测试类 另外，Gradle Test 生成的测试报告在 build/reports/tests/test/index.html 中，如下图

图15-5 Gradle Test 生成的测试报告在 build/reports/tests/test/index.html 中 测试报告的部分内容截图如下

图15-6 测试报告Summary

图15-7 UserControllerTest测试报告

图15-8 MockUserServiceTest测试报告

1.3 本章小结

本章介绍了Spring Boot项目如何测试。Spring Boot 应用对Web层测试提供强大的支持：采用MockMvc方式测试Web请求，根据传递的不用参数以及请求返回对象反馈信息进行验证测试。另外，针对 JSON 数据接口，使用 JsonPath 可以方便地进行 JSON 数据结果的校验。 提示：本章项目工程源代码： https://github.com/KotlinSpringBoot/demo_testing_and_deploy