比如常见的JavaWeb项目代码中，Controller层，DAO层以及其他仅涉及接口转发相关的方法，往往不需要单测覆盖。而业务逻辑层的各种Service则需要重点测试。
对于自定义的工具类，正则表达式等固定逻辑，也是必须要测试的。因为这部分逻辑一般都是公共且通用的，一旦逻辑错误会产生比较严重的影响。
How
好的单测一定是能够自动执行并查执行结果的，也不应当对外部有依赖，单测的执行应当是完全自动化，并且无需部署，本地IDE就能运行。
在写单侧前，不妨参考以下前人总结好的First原则。
F—Fast：快速
在开发过程中通常需要随时执行测试用例；在发布流水线中执行也必须执行，常见的就是push代码后，或者打包时先执行测试用例；况且一个项目中往往有成百上千个测试用例。
所以为了保证开发和发布效率，快速执行是单测的重要原则。这就要求我们不要像集成测试一样依赖多个组件，确保单测在秒级甚至毫秒级执行完毕。
I—Isolated：隔离
隔离性也可以理解为独立性，好的单测是每个测试用例只关注一个逻辑单元或者代码分支，保证单一职责，这样能更清晰的暴露问题和定位问题。
每个单测之间不应该产生依赖，为了保证单测稳定可靠且便于维护，单测用例之间决不能互相调用，也不能依赖执行的先后次序。
数据资源隔离，测试时不要依赖和修改外部数据或文件等其他共享资源，做到测试前后共享资源数据一致。
Fake，Stub和Mock
我们的被测试代码存在的外部依赖的行为往往是不可预测的，我们需要将这些"变化"变得可控，根据职责不同，可以分为Fake，Stubs，Mock三种。
假数据（Fake）, 一些针对当前场景构建的简化版的对象，这些对象作为数据源供我们使用，职责就像内存数据库一样。
比如在常见的三层架构中，业务逻辑层需要依赖数据访问层，当业务逻辑层开发完成后即使数据访问层没有开发完成，也能通过构建Fake数据的方式完成业务逻辑层的测试。
Copy
UserDO fakeUser = new UserDO("zhangsan", "zhangsan@163.com"); public UserVO getUser(Long userId) { // do something User user = fakeUser; // 测试阶段替换：User user = userDao.getById(userId); // do something }
Fake数据虽然可以测试逻辑，但是当数据访问层开发完毕后可能需要修改代码，将Fake数据替换为实际的方法调用来完成代码集成，显然这不是一种优雅的实现，于是便有了Stub。
桩代码（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等。如何选择合适的框架呢？
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数软件测试工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上软件测试开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！文章来源地址https://www.toymoban.com/news/detail-851419.html
！**
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-gZGtYogN-1712765891584)]文章来源：https://www.toymoban.com/news/detail-851419.html
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
到了这里，关于工作3年，还不会写单元测试？新技能get(2)，帮你突破瓶颈的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
