聊一聊,单元测试应该测试什么?
系列导航
开始
现在大公司越来越重视项目的单元测试,甚至明确要求项目的单元测试覆盖率不能低于某个值,足可见单元测试的重要性;
试想如果没有单元测试,那么如何保证代码能够正常运行呢?
测试人员做的只是业务上的集成测试,也就是黑盒测试,对单个的方法是没有办法测试的,而且,测试出的 bug 的范围也会很广,根本不能确定 bug 的范围,还得去花时间来确定 bug 出在什么地方。
另外,一个最常见的问题:写单测浪费时间? 你有没有计算过你改bug的时间(定位+修复),算一下的话你会发现时间浪费的会更多。
参考建议
关于如何写好单元测试,下面有几条建议供大家参考:
1. 测试数据外部化
测试数据大致分为两种:变化的和不变化的,对于不变的测试数据,我们完全可以写在单元测试用例代码中,也可以将数据外部化。
而对于测试数据一直在变,并且测试数据量比较大的时候可以使用测试数据外部化将数据放在测试用例的外部进行统一管理。
什么是数据外部化?就是将数据放在单元测试用例的外部统一管理,比如我们可以将一个单元测试用例中的测试数据统一放在一个CSV文件中。
我们就可以通过比如junit5中的参数测试注解@ParameterizedTest
和引入CVS文件的注解@CsvFileSource
并指定其中的resources属性指定CSV文件,numLinesToSkip = n 属性指定从第n+1行开始。这样就可以通过一个CSV文件统一管理一个单元测试用例中的数据。
我们管理测试用例中所需要的数据就只需要管理一个个CSV文件即可。
下面可以看一个案例:(其中具体的使用方法请看博客junit5系列-参数化测试)
@ParameterizedTest @CsvFileSource(resources = "/two-column.csv", numLinesToSkip = 1) void testWithCsvFileSource(String first, int second) { assertNotNull(first); assertNotEquals(0, second); }
其中,two-column.csv文件内容
Country, reference Sweden, 1 Poland, 2 "United States of America", 3
2. 构建具有特定结果的测试
- 如果方法结果具有随机性,这样的方法几乎无法测试,所以我们针对这种方法便没有办法去进行测试。
- 我们只能对根据特有数据得到特定结果的方法进行测试。
3. 测试方面全面,设计的每一方面必须有一个测试用例:
- 正面所有情景
- 负面所有情景
- 临界值
- 特殊值
4. 测试用例请尽量简洁、简短
在能完成测试的基础上尽量简洁代码,这样不仅使代码更加好看,还好维护好理解。 想想一大堆代码和几行代码你更想看哪个?
5. 测试用例尽量快
对于单元测试用例我们几乎每开发完一个方法或者修改完一个方法,我们几乎都会去运行一遍测试用例,确保没有影响到其他模块的正常运行,所以我们要尽量让你的测试方法“快!”,移除一些和单元测试无关的代码。当然,前提还是要保证测试的完整性与正确性。
6. 每次运行单元测试时,请确保100%运行成功!
这个相对来说比较简单,但是做起来是比较难的,因为可能会有多种原因导致你的测试用例失败,比如:数据过期、方法内部逻辑改变等。
这些可能会花费你的一些时间去修改,你往往可能不愿意,不过既然做了一件事,就做好一件事呗
但是如果你不注意这些小错误,这可能就会导致你的一个大流程失败,大家应该知道,我们在运行一个流程时往往一个小小的错误就导致流程整理失败!
7. 设计好你的测试
这包含的方面就比较广了,下面几个方面我认为大家应该注意的:
- 前面所说的代码在保证质量的前提下尽量简洁
- 单元测试中代码的抽象也是可以有的,我们也可以将一些可重用的代码抽象出来,提高代码的重用性和减少代码的重复。
- 给测试类测试方法起一个好名字。测试类一般是“类名+Test后缀”,可以表示对哪个类进行的测试。测试方法也是类似,“测试方法名+Test后缀”或者对一个方法的部分测试“测试方法名+测试部分作用+Test后缀”。
- 每个测试方法对被测试方法的功能断言不宜过多,如果一个方法需要多个断言进行测试,我们可以进行大致分类,将其分不到两个测试方法中,这样可以细粒度的进行测试。
8. 注意测试代码覆盖率
一个设计好的单元测试,其代码测试覆盖率也是很高的,并不要求100% 的测试代码覆盖率,但是高覆盖率的代码包含未检测到的错误的几率要低,因为其更多的源代码在测试过程中被执行。
注意:高代码覆盖不能保证测试是完美的,所以要小心!
9. 还有就是一些其他的注意点了,比如
- 不要使用print语句去输出测试结果人工判断是否正确,要使用断言
- 一些不好理解的测试最好在方法上面写明注释,便于后期理解与维护
- 使用框架进行单元测试,比如Junit5如果其中的断言支持不满足你的需求也可以使用ASsertJ框架来丰富断言,Mockito进行Mock数据等
好了,上述就是对如何写好单元测试的一些建议,如有不当,请在评论区中指出,感激不尽!
接下来,我会写一些关于单元测试如何搭建、junit5相关新语法、基于图数据库的单元测试等 欢迎关注博主和公众号[匠心Java],一起讨论~
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Taro Next H5 跨框架组件库实践
作者:凹凸曼 - JJ Taro 是一款多端开发框架。开发者只需编写一份代码,即可生成各小程序端、H5 以及 React Native 的应用。 Taro Next 近期已发布 beta 版本,全面完善对小程序以及 H5 的支持,欢迎体验! 背景 Taro Next 将支持使用多框架开发 过去的 Taro 1 与 Taro 2 只能使用 React 语法进行开发,但下一代的 Taro 框架对整体架构进行了升级,支持使用 React、Vue、Nerv 等框架开发多端应用。 为了支持使用多框架进行开发,Taro 需要对自身的各端适配能力进行改造。本文将重点介绍对 Taro H5 端组件库的改造工作。 Taro H5 Taro 遵循以微信小程序为主,其他小程序为辅的组件与 API 规范。 但浏览器并没有小程序规范的组件与 API 可供使用,例如我们不能在浏览器上使用小程序的 view 组件和 getSystemInfo API。因此我们需要在 H5 端实现一套基于小程序规范的组件库和 API 库。 在 Taro 1 和 Taro 2 中,Taro H5 的组件库使用了 React 语法进行开...
- 下一篇
在 Spring Boot 中使用 Dataway 配置数据查询接口
Dataway介绍 Dataway 是基于 DataQL 服务聚合能力,为应用提供的一个接口配置工具。使得使用者无需开发任何代码就配置一个满足需求的接口。 整个接口配置、测试、冒烟、发布。一站式都通过 Dataway 提供的 UI 界面完成。UI 会以 Jar 包方式提供并集成到应用中并和应用共享同一个 http 端口,应用无需单独为 Dataway 开辟新的管理端口。 这种内嵌集成方式模式的优点是,可以使得大部分老项目都可以在无侵入的情况下直接应用 Dataway。进而改进老项目的迭代效率,大大减少企业项目研发成本。 Dataway 工具化的提供 DataQL 配置能力。这种研发模式的变革使得,相当多的需求开发场景只需要配置即可完成交付。 从而避免了从数据存取到前端接口之间的一系列开发任务,例如:Mapper、BO、VO、DO、DAO、Service、Controller 统统不在需要。 Dataway 是 Hasor 生态中的一员,因此在 Spring 中使用 Dataway 首先要做的就是打通两个生态。根据官方文档中推荐的方式我们将 Hasor 和 Spring Boot 整合起...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境