网站建设 浙icp 0578,网页设计与网站建设教材,当地网站建设问卷调查,教育 wordpress模板1. 什么是单元测试 “在计算机编程中#xff0c;单元测试又称为模块测试#xff0c;是针对程序模块来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中#xff0c;一个单元就是单个程序、函数、过程等#xff1b;对于面向对象编程#xff0c;最…1. 什么是单元测试
“在计算机编程中单元测试又称为模块测试是针对程序模块来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中一个单元就是单个程序、函数、过程等对于面向对象编程最小单元就是方法包括基类、抽象类、或者派生类中的方法。” 摘录来自维基百科单元测试Unit Testing顾名思义就是测试一个单元这里的单元通常指一个函数或类区别于集成测试中的模块和系统。集成测试的测试过程通常存在跨系统模块的调用是一种端到端的测试而单元测试关注对象的颗粒度较小用来保障一个类或者函数是否按照预期正确的执行。
2. 为什么要写单元测试
作为保障代码质量的有效手段之一公司也在积极的推进单元测试。结合单测的实践总结了以下几点单元测试的好处认真实践过的同学应该会有共鸣。
2.1 减少BUG释放资源 上面这张图旨在说明两个问题
85%的缺陷都在代码设计阶段产生发现bug的阶段越靠后耗费成本就越高呈指数级别的增长。
单元测试是所有测试环节中最底层的一类测试是第一个环节也是最重要的一个环节。大多数缺陷是Coding阶段引入修复的成本随着软件生命周期进展不断上升。日常研发中在交付测试前我们对功能单元进行主流程、各种边界及异常单元测试的编写能有效帮助我们发现代码中的缺陷。相对于后期来自测试同学或者线上异常反馈再来进行排查定位、修复发布的成本来说单元测试的性价比是极高的。单元测试可以有效地保障代码质量给我们带来质量口碑的同时也为他人和自己减少因修复低级BUG而投入的时间能够将精力分配到其他更有意义的事情上。
2.2 为代码重构保驾护航
面对项目中历史遗留的腐化代码我们都有推倒重来的冲动但它毕竟经过了长时间的稳定性考验我们又担心重构之后出现问题。这是我们经常会遇到的境况当要重构不是非常熟悉的祖传代码又没有充足的测试资源保障的时候重构引入缺陷的风险还是很大的。
那如何保证重构不出错呢Martin Fowler在《重构改善既有代码的设计》提到
重构是很有价值的工具但只有重构还不行。要正确地进行重构前提是得有一套稳固的测试集合以帮我发现难以避免的疏漏。即便有工具可以帮我自动完成一些重构很多重构手法依然需要通过测试集合来保障。
除了需要对业务流程有足够的了解并且熟练掌握各种设计思想、模式之外单元测试是保证重构不出错的有效手段。当重构完成之后如果新的代码仍然能通过单元测试那就说明代码原有正确的逻辑未被破坏原有的外部可见行为没有发生改变。单元测试给了我们重构的信心与底气。
2.3 既是编写单测也是CodeReview
单元测试和CR是保障代码质量行之有效的两个手段。在研发交付过程中通常我们提交CR的时机较为滞后评审同学指出待优化或修复的时间点也较晚修复的风险和成本上都有所增加。
我们编写编码单元测试过程其实也是自我CodeReview的过程。在这个过程中我们对功能单元主流程、边界及异常进行测试也在自我审视代码的规范、逻辑及设计。既提高了后续提交CR的质量与评审效率也将问题提前暴露。
2.4 便于调试与验证
当项目存在多个协同方时我们只需按照约定mock出依赖项的数据无需等所有依赖的应用接口开发部署完成后再进行调试提高了我们协同的效率与质量。我们将功能需求进行拆解在开发完每一个小功能点时即可进行单元测试的编写与验证这种习惯能让我们对编码得到快速的验证反馈同时在开发完整个功能时我们需要跑一遍项目所有的单测用例可以清晰的感知本次整个功能需求的改动是否对已有业务case造成影响。
如果我们能够保障每个类、函数都能通过单元测试按照预期业务逻辑执行那整合后的功能模块或系统出问题的概率都能大大降低。从这个意义上讲单元测试也对集成测试、系统测试做了有力的支撑。
2.5 驱动设计与重构
设计和编码的时候我们很难将所有的问题都想清楚。那我们知道评判代码质量重要的的标准之一就是代码的可测性。如果对一段代码进行单测发现难于编写需要编写的case非常多或者当前的测试框架无法mock依赖对象需要依赖其他具备高级特性的测试框架时我们需要回过头来审视代码是否编码设计得不合理导致代码的可测性不高。这是个正反馈的过程让我们有针对性的进行重新设计与重构。
3. 怎样编写单元测试
3.1 单元测试框架的构建
3.1.1 单元测试框架JUnit
JUnit是目前Java语言应用最为广泛的单元测试框架用于编写和运行可重复的自动化测试它包含以下特性
用于测试期望结果的断言Assertion用于共享共同测试数据的测试工具用于方便的组织和运行测试的测试套件图形和文本的测试运行器
多数Java的开发环境都已经集成了JUnit作为单元测试的工具开源框架对JUnit 都有相应的支持
3.1.2 单元测试Mock框架
项目中依赖关系往往往非常复杂单元测试Mock框架做的事就是模拟被测试类的依赖项提供预期的行为和状态使得我们的单测可以聚焦在被测试类本身而不必受到依赖项的复杂度的影响。
这里我们讨论常用的Mockito与PowerMock两者都是作为单元测试模拟框架模拟应用中复杂的依赖对象。Mockito基于动态代理的方式实现PowerMock在Mockito基础上增加了类加载器以及字节码篡改技术使其可以实现完成对private/static/final方法的Mock。
公司使用JaCoCo来做单元覆盖率的检测当我们使用支持字节码篡改的mock工具的时候可能会造成
测试失败mock工具与jacoco同时修改字节码时引入的冲突某些类的覆盖率为0
所以我们推荐使用Mockito来作为我们的单元测试Mock框架原因有二
在版本3.4.0以后Mockito支持静态方法的mock。并且作为SpringBootTest默认集成的Mock工具所以建议大家使用高版本的Mockito并通过它来完成静态方法的Mock不提倡使用PowerMock并不是一味追求单测覆盖率而是当我们需要使用到具备高级特性mock工具时我们需要审视代码的合理性并尝试进行优化重构使其具备较好的可测性
3.1.3 依赖引入
3.1.3.1 添加JUnit的maven依赖
Springboot项目SpringMVC项目3.1.3.2 单测Mock框架的引入 3.2 单测方法的命名
3.2.1 单元测试类的规范
单元测试类需要放在工程的test目录下比如xxx/src/test/java单测类的命名按照规范应以被测类名开头并追加Test作为结尾比如ContentService - ContentServiceTest
3.2.2 单元测试方法规范
3.2.2.1 测试方法的命名
好的单元测试方法名能让我们快速知道测试的场景、意图及验证的预期。
建议采用should_{预期结果}_when_{被测方法}_given_{给定场景}
举个 反例 3.2.2.2 单测方法实现分层
单测方法的实现如果分层清晰能让代码便于理解一目了然同时也能提高后续的CR的效率
这里我们建议采用given-when-then的三段落结构
举个 3.3 单测方法的示例
3.3.1 代码案例 3.3.2 单元测试代码案例 3.4 单测的编码技巧
3.4.1 Mock依赖对象 MockitoJUnitRunner使Mockito的注解生效或者使用初始化方法MockitoAnnotations.initMocks(this)利用Mock模拟各种依赖对象使用InjectMocks将mock出的依赖对象注入到目标测试对象中。以上述代码为例单测中将docManageService注入到contentService
当然我们也可以使用直接初始化或者Spy的方式来模拟对象然后使用Setter方法来进行模拟对象的注入这里介绍了较为简便的方式。
3.4.2 Mock返回值
3.4.2.1 Mock无返回值方法 3.4.2.2 Mock方法返回值 3.4.2.3 执行方法的真实调用 3.4.2.4 Mock方法调用异常 3.4.3 自动化验证
3.4.3.1 验证依赖方法的调用 3.4.3.2 验证返回值 3.4.4 其他单测技巧处理
3.4.4.1 使用Mockito模拟静态方法 3.4.4.2 处理Mockito注册静态方法范围
在执行mvn test时如果有多个测试方法mock了Mockito.mockStatic(TagHandler.class)会报错因为静态方法是类级别的会出现注册多次的情况。可以参考下面两种解法
1.使用BeforeClass与AfterClass
BeforeClass注解方法只被执行一次运行junit测试类时第一个被执行的方法
AfterClass注解方法只被执行一次运行junit测试类时最后一个被执行的方法
示例 2.在try-with-resources构造中定义模拟 3.4.4.3 如何mock一条链式调用 Mockito提供了形如tableService.select().from(params.getTableName()).where(params.getCondition()).limit(1)链式调用解决办法mock对象的时候增加参数RETURNS_DEEP_STUBS 3.5 单测生成插件
IDEA有两款比较好用的单测自动生成插件TestMe与Diffblue这里主要介绍TestMe如果大家有比较好的插件也可以推荐。
安装在IDEA设置中的Plguins插件里搜索TestMe下载安装即可。使用在code按钮找到入口或者直接使用快捷键optionshiftQ3.生成的代码如下 自动生成插件方便初始化部分代码可以提升单测编写的效率但是也存在局限性单测名称规范、具体实现等还是需要我们完善、补充后才能正常使用
4. 如何落地单元测试
4.1 清晰单测的价值认知
不难发现公司内的项目还是外网开源项目少有工程具备完善、高质量的单元测试。上文讲了为什么要写单测这里就不再赘述了。短期来看单测无疑会带来开发工作量和开发时长的增加但是我们要从整个迭代周期来看单测的优势。从最终的效果来看坚持单元测试会有效的减少迭代中的缺陷数以及缩短需求的交付周期。
4.2 将单测纳入流程规范
4.2.1 将单元测试纳入CR标准
以往我们CR只关注核心的业务代码大多数情况下我们在评审中可以指出代码较为明显的缺陷或者不合理的设计但是各种条件case、边界及异常情况很难通过肉眼review出来。如果提交的CR中包含完善、高质量的单元测试提交、评审双方的的信心都会增强。
4.2.2 发布管控
当我们提交代码后CI可以设置运行该分支的单元测试。在发布流程中添加单测相关的管控比如单元测试通过率以及单元测试增量覆盖率等 4.3 单测工作量评估
对于单元测试工作量的评估没有一个固定的标准主要视业务逻辑复杂度而定。一般来说如果之前没有编写过单元测试在熟悉阶段可以根据需求的工作量对应增加20%30%后期熟练掌握后增加需求工作量的10%就足够了。当业务需求涉及的case较多单测需要覆盖这些必要流程时我们评估工作量时可以给自己加些时间来保障高质量的单测。
5. 后记
单元测试是一件知易行难的事情公司也在积极宣导和建设单测文化。工作方式的改变其实难度并不大难的是能够建立一致的共识并从心底认可单元测试的价值只有这样才能有效落地。
原文链接
本文为阿里云原创内容未经允许不得转载。
