《码出高效:java开发手册》八 -单元测试

前言

这章内容主要是讲单测,单元就是指一个程序分的最小单位,一般是类或者方法,在面向对象编程里,一般就是认为方法是最小单位,单测是程序功能的基本保障,在软件上线前非常重要的一环

正文

单测的好处:
1、提升软件质量:单元测试可以保障开发质量和程序的鲁棒性。开发时不断地测试能帮助发现程序的问题,进而定位和排查。越早发现问题,修复的成本也会越低;三种情况从好到坏:1、提前发现问题 2、出问题快速定位 3、跟在问题后疲于奔命,功能回归
2、 促进代码优化:在测试的过程中,工程师会优化代码的执行效率,时间空间复杂度降低就会让程序更好
3、提升研发效率:编写单测虽然会增加程序开发的时间,但后续排错和维护会大大节约时间,提升整体研发效率
4、增加重构自信:重构是非常困难的,修改一个底层结构就会影响大量上层服务,单测通过就可以提升重构的自信和勇气
单测可以说是测试人员的工作,但对开发人员来说,也是一种基本素养的体现

单元测试的基本原则

单元测试宏观要符合AIR原则,微观符合BCDE原则
新增代码应该同步增加单测用例,修改代码逻辑也要保证单测都能通过
AIR具体原则包括:
A:Automatic自动化:测试用例必须是自动化的,不允许使用System.out验证,必须使用断言验证
I:Independent独立性:独立性就是不允许用例间相互调用,否则导致运行效率降低,或者错误导致程序中断
R:Repetable可重复:主流测试框架中, JUnit 的用例执行顺序是无序的,而TestNG 支持测试用例的顺序执行,单测是可重复执行,不受外部环境影响,有提交代码就会触发单测执行
编写单测要保证粒度足够小,最好到方法级,跨类跨系统的逻辑不负责,这个属于集成测试的范围,需要保证BCDE原则:
B: Border : 边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等。
C: Correct : 正确的输入, 并得到预期的结果。
D: Design :与设计文档相结合,来编写单元测试。
E : Error :单元测试的目标是证明程序有错,而不是程序无错。为了发现代码中潜在的错误, 我们需要在编写测试用例时有一些强制的错误输入(如非法数据、异常流程、非业务允许输入等)来得到预期的错误结果。

  • 由于单测只是运行前的模拟测试,一些因素不具备,可以Mock:
    功能因素。比如被测试方法内部调用的功能不可用。
    时间因素。比如双十一还没有到来,与此时间相关的功能点。
    环境因素。政策环境,如支付宝政策类新功能,多端环境, 如PC 、手机等。
    数据因素。线下数据样本过小,难以覆盖各种线上真实场景。
    其他因素。为了简化测试编写, 开发者也可以将一些复杂的依赖采用Mock方式实现。
    可以使用硬编码实现mock,也可以使用配置文件,也可以使用一些mock框架,例如JMockit 、EasyMock 、JMock 等,使用mock可以隔离一些复杂因素,写出稳定的单测,得到稳定的结果
单元测试覆盖率

单测覆盖是指业务代码被测试的程度,从粗到细,从弱到强如下:
1、粗粒度
通常只要执行到类或方法里的代码,即使只有部分,也是覆盖了这个类或方法,通常这个覆盖率可以达到100%,但也不够
2、细粒度
(1)行覆盖
行就是代码的行,覆盖的行/代码总行数就是行覆盖率
在这里插入图片描述
如图有三个入参,5句可执行语句,编写如下测试用例
在这里插入图片描述

执行结果

在这里插入图片描述
上例中覆盖率100%,但c==3并没有执行到,并且a!=1 并且c!=3也没有执行到,可见覆盖率不代表完整程度,但由于好计算,行测也很常用
(2)分支测试
分支覆盖也叫判定覆盖,就是对各种可能情况进行覆盖判定,与下面的容颜混淆
(3)条件判定覆盖
条件判定覆盖要求所有可能条件都执行一次,并且可能结果也至少执行一次
在这里插入图片描述
在这里插入图片描述

这里的csvsource就是入参两种,023和103,分别为true和false,覆盖了可能结果
并且第二个000入参算进去,把三个条件的真假都覆盖到了
(4)条件组合覆盖
这个就是把所有条件的排列组合都来一遍,是条件判定覆盖的一个子集
在这里插入图片描述
在这里插入图片描述
这组有8组入参,就是字面意义上的3个布尔元素排组合,2的三次方,8种,如果是n个条件,就是2的n次方个,可见工作量很大
(5)路径覆盖
路径覆盖要求能够测试到程序中所有可能的路径。在testMethod 方法中,可能的路径有① a= 1, b=2 ② a1b!=2,c3 ③ a=1 ,b!=2 ,c! =3 ④ a! =1,c=3 ⑤ a !=1,c!=3
这5种。当存在“||”时, 如果第一个条件已经为true ,不再计算后边表达式的值。
而当存在“&& ” 时,如果第一个条件已经为false ,同样不再计算后边表达式的值。
这里少了3个,因为去除了判定
在这里插入图片描述
在这里插入图片描述

单元测试编写

这节介绍如何编写单测
单测框架用的多的有JUnit 和TestNG
这里用Junit5,可能有不兼容Junit4
Junit5有三个模块组成:
JUnit Platform· 用于在NM 上启动测试框架, 统一命令行、Gradle 和Maven、等方式执行测试的人口。
JUnit Jupiter: 包含JUnit5.x 全新的编程模型和扩展机制。
JUnit Vintage : 用于在新的框架中兼容运行JUnit3.x 和JUnit4.x 的测试用例。
Juint有很多注解,如下图
在这里插入图片描述
下图是一个测试类的结构
在这里插入图片描述
在这里插入图片描述
需要注意的是,@DisplayName 注解仅仅对于采用IDE 或图形化方式展示测试运行结果的场景有效

在这里插入图片描述
对于使用Maven 或Gradle 等命令行方式运行单元测试的情况,该注解中的内
容会被忽略;例如单元测试出错时,实际展示结果如下·
在这里插入图片描述
当测试用例较多时,为了更好地组织测试的结构,推荐使用JUnit 的@Nested 注解来表达有层次关系的测试用例:
在这里插入图片描述
Junit没有嵌套限制,但不建议超过三层,否则很难理解
分组测试有一些技巧,比如分为不同强度:“执行很快且很重要”的冒烟测试用例、“执行很慢但同样比较重要”的曰常测试用例,以及“ 数量
很多但不太重要”的回归测试用例。
使用Junit的@Tag注解可以区分强度
在这里插入图片描述
通过标签选择执行的用例类型, 在Maven 中可以通过配置maven-surefire-pIugin插件来实现·
在这里插入图片描述
这里运行fast而不运行slow

在Gradle 中可以通过JUnit 专用的junitPlatform 配置来实现
在这里插入图片描述
在这里插入图片描述
一些算法逻辑,计算逻辑很多,需要数据驱动测试,如果按照平常的逻辑,需要写很多用例,使用@TestFactory注解,可以将数据输入输出与测试逻辑分开,一次编写就可对各种结果进行验证
在这里插入图片描述

这里的数字意思是传入12小时,20分种,24秒,0毫秒

命名

通常测试类为被测类加Test后缀,如DemoService 的测试类应该命名为DemoServiceTest

在这里插入图片描述

如上为目录,单测代码不能再业务目录下,主流Java 测试框架如JUnit, TestNG 测试代码都是默认放在src/test/java 下的,
测试资源文件则放在src/test/resources 下,
规范单测名称有利于提高测试质量
在这里插入图片描述
如上,实例二明显更加清楚,可以猜测到时用户令牌出了问题
主流单测有两种:加test前后缀或者should…when…,比如shouldSuccess WhenDecodeUserToken
同时,避免过长名字

断言和假设

定义好测试方法后,再细化就是断言和假设了,断言是封装了一些常用逻辑,不满足则判定失败;假设类似,但它不满足,测试就直接退出,记录状态为跳过
常用的断言被封装在org.junit.jupiter.api.Assertions中,均为静态方法,如下表是一些常用断言方法
在这里插入图片描述
在这里插入图片描述
假设提供的静态方法更加简单,被封装在org.junit.jupiter.api.Assumptions 类中, 同样为静态方法
在这里插入图片描述
断言的选择,要求更精准,比如asse此Equals( 100, result) 语句优于assertTrue(100 == result) 语句。
如果没有合适的断言,也可以自己定义构造条件,然后不符合条件就用fail断言标记为失败
一般断言两个参数,第一个是预期,第二个是实际结果
在这里插入图片描述
预期加10,实际减10,运行结果
在这里插入图片描述
assertTimeout 和assertTimeoutPreemptively断言区别在于:前者结束后会继续执行记录实际操作时间,后者会直接结束
在这里插入图片描述
实际开发中,如果JUnit的断言不能满足需求,可以使用AssertJ
它的特点是流式断言,一个对象可以连接多个判断,进行多次断言

对于自定义JavaBean对象
AssertJ 通过AssertJ assertions generator 来生成对应的XxxAssert 类,然后辅助我们对模板JavaBean 对象进行断言API 判断。AssertJ
assertions generator 有相应的Maven 和Gradle Plugin , 生成这样的代码非常容易, 所以很容易实现对自定义JavaBean 对象的判断需求。它还有一些拓展,DB assertions, Guava assertions等,可以对Mybatis和Hibernate进行单测
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
如上为Junit的断言,如果用AssertJ就是这样
在这里插入图片描述
可见不同判断连接到了一起,流式断言充分利用了Java 8 之后的匿名方法和Stream 类型的特点,很好地对JUnit 断言方法进行了补充。

后记

还有一章是代码规约,这一章其实是另外一本书的缩略,之后有空会把那本书也弄过来

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值