跨层单元测试de歪门邪道
一般来说，Spring应用的单元测试都是发生在该应用的某个层,例如controller、service或者是dao层。 而service层既是应用服务的主要实现者，也是重点被测试的对象，其余各层，如controller层一般以线性代码为主，缺少业务逻辑，可以少测甚至是不测。 不过也有些团队会认为，既然应用的入口是controller,那么从controller层入口对服务进行测试，更贴合用户的场景，这部分的测试也更有业务价值，也更能提升对产品质量的信心。如果某些测试场景或者分支是通过controller层无法达到的，那么这部分的测试优先级就可以降低。 因此，笔者就见到过controller连同service一起进行测试的场景，也就是所谓的跨层单元测试 还是以TestLink4J为例,有如下用例
package com.testlink4j.controller;
//import
@Slf4j
public class KeywordsControllerServiceTest {
@InjectMocks
private KeywordsServiceImpl keywordsService;
@InjectMocks
KeywordsRestController keywordsRestController;
@Mock
KeywordsMapper keywordsMapper;
@BeforeEach()
public void setup() {
MockitoAnnotations.initMocks(this);
ReflectionTestUtils.setField(keywordsRestController,
"keywordsService",keywordsService);
}
@Test
public void CreateKeywordsSuccessfullyTest() {
Keywords keywords=Keywords.builder().id(666).keyword("tester")
.testproject_id(333).notes("tester").build();
Mockito.when(keywordsMapper.selectByPrimaryKey(1)).thenReturn(keywords);
Keywords responseString=keywordsRestController.findKeywordById(1);
log.info(JSON.toJSONString(responseString));
assertThatJson(responseString).isEqualTo(keywords);
}
}
用例调用了keywordsRestController.findKeywordById方法，并验证其返回结果，实现了对keywordsRestController和keywordsService的测试，也就是controller和service两层的测试。 以下是执行的日志：
22:01:36.569 [main] DEBUG org.springframework.test.util.ReflectionTestUtils - Setting field 'keywordsService' of type [null] on target object [com.testlink4j.controller.KeywordsRestController@422c3c7a] or target class [class com.testlink4j.controller.KeywordsRestController] to value [com.testlink4j.service.impl.KeywordsServiceImpl@18230356]
22:01:36.747 [main] INFO com.testlink4j.controller.KeywordsControllerServiceTest - {"id":666,"keyword":"tester","notes":"tester","testproject_id":333}
这其中的运行逻辑是这样的
- 首先对keywordsMapper进行mock
- 将被mock的keywordsMapper注入到keywordsService
- 将keywordsService再注入到keywordsRestController（此处要用到歪门邪道哦），从而完成被测对象的实例化
- 利用Mockito准备测试桩
- 执行用例并验证结果
简单介绍一下案例中的代码是如何实现上述逻辑的，
- 使用@InjectMocks分别对Service和Controller进行注解，从而利用来实现这两个对象的实例化。不是使用@Autowired等方式以Spring容器托管的方式来实现被测对象的实例化，这其中也利用了@InjectMocks在mock注入时的slient injection特性，也就是注入失败时不会抛出异常，而是使用默认值（此时keywordsRestController中的keywordsService为null），而Spring容器在实例化bean如果遇到错误，则会抛出异常，导致用例无法执行。
- 通过ReflectionTestUtils这个Spring提供的反射注入工具，将@InjectMocks提供的keywordsService实例注入到keywordsRestController中名为keywordsService的变量中。这样，当测试用例调用keywordsRestController的接口时，就可以顺利执行并调用keywordsService的方法了，从而触发了测试桩完成测试。 3）一定是先实例化被测对象，然后再注入哦。 这2行代码的顺序一定不能反了
MockitoAnnotations.initMocks(this);
ReflectionTestUtils.setField(keywordsRestController,
"keywordsService",keywordsService);本文参与 腾讯云自媒体分享计划，分享自微信公众号。
原始发表：2020-11-06，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读