Spock注意事项-groovy的maven编译插件版本不兼容问题
有些项目虽然在Idea里执行spock单元测试时一切正常,但通过maven执行或在公司内部一些CICD系统中运行spock的单测时可能会遇到以下异常: Execution default of goal org.codehaus.gmavenplus:gmavenplus-plugin:1.6:compileTests failed 或者是这种异常: Unable to determine Gro
有些项目虽然在Idea里执行spock单元测试时一切正常,但通过maven执行或在公司内部一些CICD系统中运行spock的单测时可能会遇到以下异常: Execution default of goal org.codehaus.gmavenplus:gmavenplus-plugin:1.6:compileTests failed 或者是这种异常: Unable to determine Gro
Mock 按照Spock官方文档(https://spockframework.org/spock/docs/2.0/interaction_based_testing.html)的定义: 描述规范下的对象与其合作者之间(强制)交互的行为。 说人话就是Mock()的对象是一个虚拟类,用于替换真实的类,为每个方法调用返回一个默认值:引用类型是null,基本类型为 0 或 false,比如可以把调用其
之前的Spock系列mock静态方法主要是通过使用PowerMock实现的,但是使用JMock的同学也挺多的,所以这篇文章讲下在Spock中如何使用JMockit来mock静态方法。 比如下面的业务代码demo,记录日志的logger对象是调用LoggerServiceFactory工厂类的静态方法获取的,这时候就可以使用JMockit把他的静态方法getLoggerService给mock掉,因
如果你在Spock中使用powermock去mock掉jdk类的静态方法,可能会出现powermock不兼容的问题(感谢"有1024个人"这位朋友的反馈,原文见之前这篇文章的评论:https://javakk.com/281.html)。 比如有下面这个要测试的类,里面调用了java.util.Calendar获取当前的年份,其他代码会调用这个方法,我们可能需要对返回的年份进行mock来测试不同的
叫"高级语法"有点言过其实了,标题党嫌疑。主要是针对我们业务代码中一些比较特殊的场景可以考虑使用。 先简单说下Groovy的闭包概念,官方定义: Groovy中的闭包是一个开放,匿名的代码块,可以接受参数,返回值并分配给变量 语法如下: { [closureParameters -> ] statements } 其中[closureParameters->]代表参数,多个参数用逗号分
Spock和Mockito注解混用问题 因为Spock并不支持Mockito和power mock的@InjectMocks和@Mock的组合,运行时会报错,如果你一定要使用对应的功能可以引入Mockitio为Spock专门开发的第三方工具:spock-subjects-collaborators-extension使用@Subject和@Collaborator代替@InjectMocks和@M
前面的几篇文章介绍了Spock的各种语法,和power mock的结合,以及注意事项,这篇做个总结,让大家对Spock有个全面客观的了解 Spock优点 遵循BDD模式、功能强大、语义规范、可读性好、易于维护、富有表现力 更灵活的控制测试行为,专注代码的逻辑测试而不是书写语法上 用自然语言描述测试步骤(非技术人员也能看懂测试用例) 兼容mock框架,可以和项目中的java单测代码共存,降低迁移成本
Spock虽然好用,但要应用到实际项目中还是需要注意几个问题,下面讲下我们公司在使用过程中遇到的一些问题和解决方案 版本依赖 要使用Spock首先需要引入相关依赖,目前使用下来和我们项目兼容的Spock版本是1.3-groovy-2.5,以maven为例(gradle可以参考官网),完整的pom依赖如下: <spock.version>1.3-groovy-2.5</spock.
这是Spock系列的第九篇文章,这一篇介绍在实际使用Spock的过程中如何把一些常用的测试方法抽出来,封装成基类使用 BaseSpock 在前面几篇文章讲解Spock结合power mock实现静态方法mock功能时,示例代码里经常会用到LogUtils等工具类的静态方法去记录日志,那我们就可以把LogUtils类的mock代码抽到一个公共类中,然后我们的测试类去继承我们自己实现的公共类 比如我们
这是Spock系列的第八篇文章,上一篇介绍了Spock如何使用power mock测试静态方法,这篇讲解Spock自带的mock功能如何和power mock组合使用,发挥更强大的作用 动态mock静态方法 (spock where + power mock) 在上一篇的例子中使用power mock让静态方法返回一个指定的值,那能不能每次返回不同的值呢? 我们先看下什么场景需要这样做: /**
这是Spock系列的第七篇文章,本篇主要讲解Spock如何扩展第三方power mock对静态方法进行测试 实现原理 前面的文章讲到Spock的单测代码是继承自Specification基类,而Specification又是基于Junit的注解@RunWith()实现的,代码如下: @RunWith(Sputnik.class) @SuppressWarnings("UnusedDeclarati
这是Spock系列的第六篇文章,本篇讲解如何针对void方法,即无返回结果的方法测试 void方法 void方法的测试不能像前面几篇介绍的那样在then标签里验证返回结果,因为void方法没有返回值 一般来说无返回值的方法,内部逻辑会修改入参的属性值,比如参数是个对象,那代码里可能会修改它的属性值,虽然没有返回,但还是可以通过校验入参的属性来测试void方法 还有一种更有效的测试方式,就是验证方法
这是Spock系列的第五篇文章,这一篇主要讲使用Spock如何测试代码中抛异常的场景 背景 有些方法需要抛出异常来中断或控制流程,比如参数校验的逻辑: 不能为null,不符合指定的类型,list不能为空等验证,如果校验不通过则抛出checked异常,这个异常一般都是我们封装的业务异常信息,比如下面的业务代码: /** * 校验请求参数user是否合法 * @param user * @throws
这是Spock系列的第四篇文章,在第二篇讲单元测试开发成本和效率问题时,提到了如何测试复杂的if else场景,分别使用Junit和Spock的实现,以及Spock的优势在哪里,这一篇会详细讲解Spock代码的语法 一. expect + where 如果业务比较复杂,对应的代码实现会有不同的分支逻辑,类似下面的伪代码: if () { if () { // 代码逻辑 } else { // 代码
这是Spock系列的第三篇文章,从本篇开始会列举一些典型业务场景下如何使用Spock开发测试代码,具体功能和用法,以及groovy语法特点等(为方便演示,所有业务代码均为示例代码) Spock自带的mock用法 在上一篇讲单元测试代码可读性和维护性的问题时举了一种业务场景,即接口调用,我们的用户服务需要调用用户中心接口获取用户信息,代码如下: /** * 用户服务 * @author 公众号:Ja
这是Spock系列的第一篇文章,整个专辑会介绍Spock的用途,为什么使用Spock?它能给我们带来什么好处?它和JUnit、JMock、Mockito有什么区别?我们平时写单元测试代码的常见问题和痛点,Spock又是如何解决的,Spock的代码怎么编写以及Spock的优势和缺点等内容,让大家对Spock有个客观的了解。 Spock是什么? 斯波克是国外一款优秀的测试框架,基于BDD思想,功能强大