工作3年，还不会写单元测试？新技能get，2024-2024京东软件测试面试真题解析

桩代码（Stub）是用来代替真实代码的临时代码，是在测试环境对依赖接口的一种专门实现。

比如，UserService中调用了UseDao，为了对UserService中的函数进行测试，这时候需要构建一个UserDao接口的实现类UserDaoStub（返回Fake数据），这个临时代码就是所谓的桩代码。

Copy

public class UserDaoStub implements UserDao { UserDO fakeUser = new UserDO(); { fakeUser.setUserName("zhangsan"); fakeUser.setEmail("zhangsan@163.com"); LocalDateTime dateTime = LocalDateTime.of(2021, 7, 1, 12, 30, 0); fakeUser.setCreateTime(dateTime); fakeUser.setUpdateTime(dateTime); } @Override public UserDO getById(Long id) { if (Objects.isNull(id) || id <= 0) { return new UserDO(); } return fakeUser; } }

这种面向接口编程，使得在不同场景下通过不同的实现类替换接口的编程设计原则就是我们常说的里氏替换原则。

Mock 代码和桩代码非常类似，都是用来代替真实代码的临时代码。不同的是在被调用时，会记录被调用信息，执行完毕后验证执行动作或结果是否符合预期。

对于 Mock 代码来说，我们的关注点是 Mock 方法有没有被调用，以什么样的参数被调用，被调用的次数，以及多个 Mock 函数的先后调用顺序。

Copy

@Test public void testAddUser4SendEmail() { // GIVEN： AddUserRequest fakeAddUserRequest = new AddUserRequest("zhangsan", "zhangsan@163.com"); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertTrue(addResult.isSuccess()); // 验证sendVerifyEmail的调用1次，并且调用参数为我们fake数据中指定的邮箱 verify(emailService, times(1)).sendVerifyEmail(any()); verify(emailService).sendVerifyEmail(fakeAddUserRequest.getEmail()); }

当然，我们也可以通过修改Stub的实现，达到和Mock一样的效果。

Copy

public class EmailServiceStub implements EmailService{ public int invokeCount = 0; @Override public boolean sendVerifyEmail(String email) { invokeCount ++; // do something return true; } } public class UserServiceImplTest { AddUserRequest fakeAddUserRequest; private UserServiceImpl userService; private EmailServiceStub emailServiceStub; @Before public void init() { fakeAddUserRequest = new AddUserRequest("zhangsan", "zhangsan@163.com"); emailServiceStub = new EmailServiceStub(); userService= new UserServiceImpl(); userService.setEmailService(emailServiceStub); } @Test public void testAddUser4SendEmail() { // GIVEN: fakeAddUserRequest // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN：发送邮件接口被调用次数是否为1 Assert.assertEquals(emailServiceStub.invokeCount, 1); } }

Stub和Mock的区别

Stub和Mock的区别在于，Stub偏向于结果验证，Mock则更加偏向于行为验证。

比如，测试addUser方法时，如果是Stub方式则关注方法返回结果，即用户是否添加成功，邮件是否发送成功；而Mock方式则倾向于本次添加的行为验证，比如sendEmail方法调用次数等。

Mock替代Stub

Mock和Stub本质上是不同的，但是随着各种Mock框架的引入，Stub和Mock的边界越来越模糊，使得Mock不仅可以进行行为验证，同样也具备Stub对接口的假实现的能力。

目前大多数的mock工具都提供mock退化为stub的支持，以Mockito为例，我们可以通过anyObject(), any等方式对参数的进行匹配；使用verify方法可以对方法的调用次数和参数进行检验，这和stub就几乎没有本质区别了。

Copy

when(userDao.insert(any())).thenReturn(1L); when(emailService.sendVerifyEmail(anyString())).thenReturn(true);

stub理论上也是可以向mock的方向做转化，上文也提及stub是可以通过增加代码来实现一些expectiation的特性，而从使得两者的界限更加的模糊。

所以，如果对于Stub和Mock的概念还是比较模糊，也不必过度纠结，这并不影响写出优秀的单测。

R—Repeatable：可重复执行

单测是可以重复执行的，不能受到外界环境的影响。 同一测试用例，即使是在不同的机器，不同的环境中运行多次，每次运行都会产生相同的结果。

避免隐式输入（Hidden imput），比如测试代码中不能依赖当前日期，随机数等，否则程序就会变得不可控从而变得不可重复执行。

S—Self-verifying：自我验证

单测需要通过断言进行结果验证，即当单测执行完毕之后，用来判断执行结果是否和假设一致，无需人工检查是否执行成功。

当然，除了对执行结果进行检查，也能对执行过程进行校验，如方法调用次数等。下面是笔者在工作中经常见到的写法，这些都是无效的单测。

Copy

// 直接打印结果 public void testAddUser4DbError() { // GIVEN fakeAddUserRequest.setUserName("badcase"); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN System.out.println(addResult); } // 吞没异常失败case public void testAddUser4DbError() { // GIVEN fakeAddUserRequest.setUserName("badcase"); // WHEN try { ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN Assert.assertTrue(addResult.isSuccess()); } catch(Exception e) { System.out.println("测试执行失败"); } }

正解如下：

Copy

@Test public void testAddUser4DbError() { // GIVEN fakeAddUserRequest.setUserName("badcase"); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN Assert.assertEquals(addResult.getMsg(), "添加用户失败，请稍后重试"); }

T—Timely&Thorough：及时，全面

理想状态当然是TDD模式开发，即测试驱动开发。如前面提到的，编写代码逻辑之前写最佳，边开发边写次之，等代码稳定运行再来补单测收益可能是最低的。

除了及时性，笔者认为T应当有另一层含义，即全面性（Thorough）。理想情况下每行代码都要被覆盖到，每一个逻辑分支都必须有一个测试用例。

不过想要100%的测试覆盖率是非常耗费精力的，甚至会和我们最初提高效率的初衷相悖。所以花合理的时间抓出大多数bug，要好过穷尽一生抓出所有bug。

通常情况下我们要至少考虑到参数的边界，特殊值，正常场景(与设计文档结合)以及异常场景，保证我们的核心流程是正确的。

Mock框架简介

========

工欲善其事必先利其器，选择一个合适的Mock框架与手动实现Stub比，往往能够让我们的单测事半功倍。

需要说明的是，Mock框架并不是必须的。正如上文所说，我们可以实现Stub代码来隔离依赖，当需要使用到Mock对象时，我们只需要对Stub的实现稍作修改即可。

市面上有许多Mock框架可供选择，如常见的Mockito，PowerMock，Spock，EasyMock，JMock等。如何选择合适的框架呢？

如果你想半个小时就能上手，不妨试试Mockito，绝对如丝般顺滑！当然，如果有时间并且对Groovy语言感兴趣，不妨花半天时间了解下Spock，能让测试代码更加精简。

以下是几种常用的Mock框架对比，不知道怎么选时，不妨根据现状，需要注意的是，大部分Mock框架都不支持Mock静态方法。

单测实战

====

写单测一般包括3个部分，即Given（Mock外部依赖&准备Fake数据），When（调用被测方法）以及Then（断言执行结果），这种写法和Spock的语法结构也是一致的。

为了更好的理解单元测试，笔者将针对如下代码，分别使用Mockito和Spock写一个简单的示例，让大家感受一下两者的各自的特点和不同。

Copy

@Service @AllArgsConstructor @NoArgsConstructor public class UserServiceImpl implements UserService { @Autowired private UserDao userDao; @Autowired private EmailService emailService; public ResultDTO<Long> addUser(AddUserRequest request) { // 1. 校验参数 ResultDTO<Void> validateResult = validateAddUserParam(request); if (!validateResult.isSuccess()) { return ResultDTO.paramError(validateResult.getMsg()); } // 2. 添加用户 UserDO userDO = request.buildUserDO(); long id = userDao.insert(userDO); // 3. 添加成功，返回验证激活邮件 if (id > 0) { emailService.sendVerifyEmail(request.getEmail()); return ResultDTO.success(id); } return ResultDTO.internalError("添加用户失败，请稍后重试"); } /** * 校验添加用户参数 */ private ResultDTO<Void> validateAddUserParam(AddUserRequest request) { if (Objects.isNull(request)) { return ResultDTO.paramError("添加用户参数不能为空"); } if (StringUtils.isBlank(request.getUserName())) { return ResultDTO.paramError("用户名不能为空"); } if (!EmailValidator.validate(request.getEmail())) { return ResultDTO.paramError("邮箱格式错误"); } return ResultDTO.success(); } }

基于Mockito的单测示例如下，需要注意的下面是纯java代码，没有对象显示调用的方法都是已经静态导入过的。

Copy

@RunWith(MockitoJUnitRunner.class) public class UserServiceImplTest { // Fake：需要提前构造的假数据 AddUserRequest fakeAddUserRequest; // Mock: mock外部依赖 @InjectMocks private UserServiceImpl userService; @Mock private UserDao userDao; @Mock private EmailService emailService; @Before public void init() { fakeAddUserRequest = new AddUserRequest("zhangsan", "zhangsan@163.com"); when(userDao.insert(any())).thenReturn(1L); when(emailService.sendVerifyEmail(anyString())).thenReturn(true); } @Test public void testAddUser4NullParam() { // GIVEN fakeAddUserRequest = null; // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertEquals(addResult.getMsg(), "添加用户参数不能为空"); } @Test public void testAddUser4BadEmail() { // GIVEN fakeAddUserRequest.setEmail(null); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertEquals(addResult.getMsg(), "邮箱格式错误"); } @Test public void testAddUser4BadUserName() { // GIVEN fakeAddUserRequest.setUserName(null); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertEquals(addResult.getMsg(), "用户名不能为空"); } @Test public void testAddUser4DbError() { // GIVEN when(userDao.insert(any())).thenReturn(-1L); // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertEquals(addResult.getMsg(), "添加用户失败，请善后重试"); } @Test public void testAddUser4SendEmail() { // GIVEN // WHEN ResultDTO<Long> addResult = userService.addUser(fakeAddUserRequest); // THEN assertTrue(addResult.isSuccess()); verify(emailService, times(1)).sendVerifyEmail(any()); verify(emailService).sendVerifyEmail(fakeAddUserRequest.getEmail()); } }

正如上文提到的，Spock能够让代码更加精简，尤其是在代码逻辑分支比较多的场景下。下面是基于Spock的单测。

Copy

class UserServiceImplSpec extends Specification { UserServiceImpl userService = new UserServiceImpl(); AddUserRequest fakeAddUserRequest; def userDao = Mock(UserDao) def emailService = Mock(EmailService) def setup() { // Fake数据创建 fakeAddUserRequest = new AddUserRequest(userName: "zhangsan", email: "zhangsan@163.com") // 注入Mock对象 userService.userDao = userDao userService.emailService = emailService } def "testAddUser4BadParam"() { given: if (Objects.isNull(userName) || Objects.is(email)) { fakeAddUserRequest = null } else { fakeAddUserRequest.setUserName(userName) fakeAddUserRequest.setEmail(email) } when: def result = userService.addUser(fakeAddUserRequest) then: Objects.equals(result.getMsg(), resultMsg) where: userName | email | resultMsg null | null | "添加用户参数不能为空" "Java填坑笔记" | null | "邮箱格式错误" null | "javaTKBJ@163.com" | "用户名不能为空" } def "testAddUser4DbError"() { given: _ * userDao.insert(_) >> -1L when: def result = userService.addUser(fakeAddUserRequest) then: Objects.equals(result.getMsg(), "添加用户失败，请稍后重试") } def "testAddUser4SendEmail"() { given: _ * userDao.insert() >> 1 when: def result = userService.addUser(fakeAddUserRequest) then: result.isSuccess() 1 * emailService.sendVerifyEmail(fakeAddUserRequest.getEmail()) } }

思考总结

====

在验证商业模式之前，时刻要想考虑投入产出比。时间和商业成本太高不利于产品快速推向市场，所以什么时候推广单测，需要更高阶的人决策。

测试不可能序错误，单测也不例外。单测只测试程序单元自身的功能。因此，它不能发现集成错误、性能、或者其他系统级别的问题。

单测能够提高代码质量，驱动代码设计，帮助我们更早发现问题，保障持续优化和重构，是工程师的一项必备技能。

参考资料：

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数软件测试工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上软件测试开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

！**

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-IkcWAhZy-1712765922968)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！