What you can expect from Spock 2?

What you can expect from Spock 2?
Marcin Zajączkowski
Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
Warszawa, 25 June 2022

View Slide

Presentation goal
Make you familiar with "new and noteworthy" in Spock 2
(and encourage to migration)

View Slide

About me
Areas of expertise
Automatic Testing / TDD
Software Craftsmanship / Code Quality
Deployment Automation / Continuous Delivery
Concurrency / Parallel Computing / Reactive Systems
.
FOSS projects author and contributor
(minor) Spock committer
blogger - https://blog.solidsoft.pl/
trainer

View Slide


View Slide

Presentation plan
state of Spock in 2022
key reasons why 2.0 cannot be missed
some other new features and enhancements
Spock 2.1, 2.2 and beyond
summary

View Slide

State of Spock in 2022

View Slide

State of Spock in 2022
actively developed
new features and bugﬁxes
1 main maintainer
3 active committers
group of contributors
Spock 2.0 M1 released in December 2019
followed by 5 more milestone releases
Spock 2.0 Final - May 2021
2.1 and 2.2-M1 - Feb 2022

View Slide

Key changes in Spock 2

View Slide

#1 - JUnit Platform (JUnit 5) as a base

View Slide

JUnit 5 vs JUnit Platform
Diagram by Marc Philipp from JUnit team

View Slide

JUnit 5 vs JUnit Platform
Diagram by Marc Philipp from JUnit team
Spock
Spock

View Slide

Spock 2 and JUnit 4 Rules
Spock 1.x was JUnit 4 Runner
(most of) JUnit 4 Rules could be used

View Slide

Spock 2.x uses JUnit Platform
JUnit 5 doesn't support @Rule anymore *
some rules very popular - e.g. @Rule TemporaryFolder

View Slide

Spock 2.x uses JUnit Platform
JUnit 5 doesn't support @Rule anymore *
some rules very popular - e.g. @Rule TemporaryFolder
.
new artifact org.spockframework:spock-junit4 wrapps @Rules into Spock extensions
ease Spock 1.x -> 2.x migration
in long run, it is good to switch to native Spock extensions if possible/feasible
(most of) JUnit 4 Rules should work

View Slide

#2 - Groovy 3 support

View Slide

Groovy 3 support
one Spock codebase to support both Groovy 2 and 3
some challenges - Groovy 3 is not backward compatible
a few bugs/changes found in Groovy and reported before 3.0.0-ﬁnal
Spock 2.0-M2 released right after Groovy 3.0.0-ﬁnal
just in time as 1.3 and 2.0-M1 had blocked execution with 3.0*

View Slide

Groovy 3 support
.
binary artifact variants for -groovy-2.5 and -groovy-3.0
spock-groovy2-compat implicitly added to classpath for Groovy 2 version

View Slide

Groovy 3 support
.
Important. Do not mix spock-*-2.0-groovy.2-5 jars with groovy-core-3.0 jars
weird runtime errors might happen

View Slide

Groovy 3 support
.
Important. Do not mix spock-*-2.0-groovy.2-5 jars with groovy-core-3.0 jars
weird runtime errors might happen
2.0-M
2
2.0-M
2

View Slide

#3 - Test unrolling by default

View Slide

Test unrolling by default
no need to put @Unroll at the method or class level
no need to use 3rd-party extension spock-global-unroll

View Slide

no need to put @Unroll at the method or class level
no need to use 3rd-party extension spock-global-unroll
@Unroll to alternative display name in test report
#placeholder in method name works by default
for ﬁelds and static methods with no parameter
provided: #featureName, #iterationIndex
@Rollup for explicitly disabling unrolling
at method or test level

View Slide

new default unrolling pattern (must be unique per iteration)
e.g. feature name [param1: 123, param2: bar, #0]
custom conﬁgurable with unroll { defaultPattern ... }
conﬁgurable with SpockConfig.groovy mechanism
unroll {
unrollByDefault false //if really needed in specific test suites (enabled by default)
defaultPattern '#featureName[#iterationIndex]' //if other format is preferred
validateExpressions false //if temporary needed during migration (enabled by default)
}

View Slide

unroll {
}
broken placeholders fail test by default
in 1.x only easy to ignore warning
possible to disable for interim period
with unroll { validateExpressions false }

View Slide

unroll {
}
broken placeholders fail test by default
in 1.x only easy to ignore warning
possible to disable for interim period
with unroll { validateExpressions false }
2.0-
2.0-
M
1/M
3
M
1/M
3

View Slide

Parameterized test enhancements
semicolon(s) as alternative to | and || (which could generate warnings in IDE)
where:
a ; b ;; c
1 ; 2 ;; 3
4 ; 2 ;; 6
9 ; 4 ;; 13

View Slide

Parameterized test enhancements
semicolon(s) as alternative to | and || (which could generate warnings in IDE)
where:
a ; b ;; c
1 ; 2 ;; 3
4 ; 2 ;; 6
9 ; 4 ;; 13
two or more underscores split data table (useful for number of imput params)
where:
_____
a | b
1 | 3
7 | 1
0 | 9
___________
c || result
1 || 22
1 || 41
5 || 16

View Slide

#4 - Parallel test execution

View Slide

Parallel test execution
parallelism at speciﬁcations and/or features level
two modes: same thread or concurrent (4 combinations)
global mode can be overridden per speciﬁcation or feature with @Execution

View Slide

Parallel test execution
parallelism at specifications and/or features level
two modes: same thread or concurrent (4 combinations)
global mode can be overridden per specification or feature with @Execution
fine parallelism tuning for non pure unit tests
@ResourceLock - RO/RW lock for specification/feature
with predefined resources (SYSTEM_PROPERTIES, SYSTEM_OUT, TIME_ZONE, ...)
or custom resources (by name)
@Isolated for global state changes

View Slide

Parallel test execution - example with locks
@ResourceLock(Resources.SYSTEM_PROPERTIES)
class ParallelResourceLockSpec extends Specification {
def "should load configuration from valid config property"() {
given:
System.setProperty(CONFIG_PROPERTY_KEY, VALID_CONFIG)
expect:
loadConfiguration() != null
cleanup:
System.clearProperty(CONFIG_PROPERTY_KEY)
}
def "should fail on loading configuration from invalid config property"() {
given:
System.setProperty(CONFIG_PROPERTY_KEY, INVALID_CONFIG)
when:
loadConfiguration()
then:
thrown(UnableToLoadConfigurationException)
cleanup:
System.clearProperty(CONFIG_PROPERTY_KEY)
}
can be simpliﬁed

View Slide

Parallel test execution - example with locks - simpliﬁed
@RestoreSystemProperties //@ResourceLock(Resources.SYSTEM_PROPERTIES) is automatically acquired
class ParallelResourceLockSimplifiedSpec extends Specification {
def "should load configuration from valid config property"() {
given:
System.setProperty(CONFIG_PROPERTY_KEY, VALID_CONFIG)
expect:
loadConfiguration() != null
}
def "should fail on loading configuration from invalid config property"() {
given:
System.setProperty(CONFIG_PROPERTY_KEY, INVALID_CONFIG)
when:
loadConfiguration()
then:
thrown(UnableToLoadConfigurationException)
}
//...
}
@RestoreSystemProperties automatically acquires
@ResourceLock(Resources.SYSTEM_PROPERTIES) - it is always needed here anyway

View Slide

Parallel test execution - ctd.
configurable parallel thread pool
dynamic(BigDecimal factor) - factor of available vCPUs
dynamicWithReservedProcessors - factor minus reserved vCPUs
fixed - given number of threads
custom - own implementation
by default all logical CPUs minus 2 (e.g. for 12 vCPUs - 10 threads)
can be defined via annotations or global configuration

View Slide

runner {
parallel {
enabled true //disabled by default
dynamicWithReservedProcessors(1.0, 2) //default value
defaultSpecificationExecutionMode ExecutionMode.CONCURRENT //default value
defaultExecutionMode ExecutionMode.CONCURRENT //default value
}
}

View Slide

runner {
parallel {
enabled true //disabled by default
dynamicWithReservedProcessors(1.0, 2) //default value
defaultSpecificationExecutionMode ExecutionMode.CONCURRENT //default value
defaultExecutionMode ExecutionMode.CONCURRENT //default value
}
}
Still in
Still in
beta!
beta!
2.0-M
4
2.0-M
4

View Slide

Other changes

View Slide

Updated JVM-based conditions
used for conditional testing with @Requires/@IgnoreIf/@PendingFeatureIf
isJavaXX() and isJavaXXCompatible() up to Java 23
in Spock 1.3 only up to Java 11
new isJavaVersion(XX) and isJavaVersionCompatible(XX) for even more distant future

View Slide

Updated JVM-based conditions
used for conditional testing with @Requires/@IgnoreIf/@PendingFeatureIf
isJavaXX() and isJavaXXCompatible() up to Java 23
in Spock 1.3 only up to Java 11
new isJavaVersion(XX) and isJavaVersionCompatible(XX) for even more distant future
2.0-
2.0-
M
2/final
M
2/final

View Slide

Reduced Groovy dependencies
Groovy 2.0 - groovy.jar + Groovy modules (vs still available groovy-all.jar)
possible version clashes - quite common defensive exclusions

org.codehaus.gmaven.runtime
YYY
1.2

org.codehaus.groovy
*

org.codehaus.groovy
groovy-all
${groovy.version}


View Slide

Reduced Groovy dependencies
Groovy 2.0 - groovy.jar + Groovy modules (vs still available groovy-all.jar)
possible version clashes - quite common defensive exclusions
Groovy 2.5 - Maven's BOM (Bill Of Materials)
groovy-all no longer real JAR with classes
Spock 1.2+ change from groovy-all.jar to groovy.jar + Groovy modules
a lot of Groovy modules provided by default (for historical reasons)
test('org.spockframework:spock-core:1.3-groovy-2.5') {
exclude group: 'org.codehaus.groovy' //get rid of all dependant groovy modules
}
test "org.codehaus.groovy:groovy:${groovyVersion}" //apply only those needed
test "org.codehaus.groovy:groovy-json:${groovyVersion}"
test "org.codehaus.groovy:groovy-templates:${groovyVersion}"

View Slide

Reduced Groovy dependencies - Spock 2.0
spock-core in fact doesn't need Groovy modules
Spock 2.0+ - just groovy.jar dependency
less burden on classpath

View Slide

possible ClassNotFoundException with groovy.sql.Sql, groovy.json.JsonSlurper,
groovy.util.XmlParser if used directly in test
explicit dependency of groovy-sql, groovy-json, ... should help
test "org.spockframework:spock-core:2.0-groovy-3.0"
test "org.codehaus.groovy:groovy-json:${groovyVersion}" //just Groovy modules used in tests - if any

View Slide

possible ClassNotFoundException with groovy.sql.Sql, groovy.json.JsonSlurper,
groovy.util.XmlParser if used directly in test
explicit dependency of groovy-sql, groovy-json, ... should help
test "org.spockframework:spock-core:2.0-groovy-3.0"
test "org.codehaus.groovy:groovy-json:${groovyVersion}" //just Groovy modules used in tests - if any
Breaking
Breaking
change
change
2.0-M
3
2.0-M
3

View Slide

Removed junit4.jar dependency
JUnit 5 used by default, but initially junit4.jar still on classpath
removed entirely in M3 after extra refactoring
spock-junit4 still provides junit4.jar

View Slide

@Before/@After/... annotations used only if spock-junit4 available
considered as deprecated

View Slide

@Before/@After/... annotations used only if spock-junit4 available
considered as deprecated
changed order of ﬁxture methods execution
1.3: beforeClass, setupSpec, before, setup, cleanup, after, setup, before,
cleanup, after, cleanupSpec, afterClass
2.0: setupSpec, beforeClass, setup, before, cleanup, after, setup, before,
cleanup, after, cleanupSpec, afterClass

View Slide

Removed junit4.jar dependency - ctd.
setup/cleanup logic in trait
trait TimeResetGuardian {
@After //→ cleanup() ? - BROKEN
def resetTime() {
//resets global time variable to "now" in poorly written legacy integration tests
}
}
class Legacy142InegrationTest extends Specification implements TimeResetGuardian {
def cleanup() {
//some spec specific cleanup
}
...
}

View Slide

def resetTime() {
}
}
def cleanup() {
}
...
}
cannot be easily replaced with 2x cleanup()s (or cleanupSpec()s)
Groovy doesn't support mixing custom AST transformations with traits
spock-junit4.jar with @Before/@After has to be used

View Slide

def resetTime() {
}
}
def cleanup() {
}
...
}
cannot be easily replaced with 2x cleanup()s (or cleanupSpec()s)
Groovy doesn't support mixing custom AST transformations with traits
spock-junit4.jar with @Before/@After has to be used
Breaking
Breaking
change
change
2.0-M
3
2.0-M
3

View Slide

Injecting Spring beans into @Shared ﬁles
long awaited feature (April 2015)
before that only various hacks workarounds were possible

View Slide

Injecting Spring beans into @Shared ﬁles
long awaited feature (April 2015)
before that only various hacks workarounds were possible
@EnableSharedInjection to enable per speciﬁcation (test class)
@EnableSharedInjection
class KafkaListenerIntegrationSpec extends IntegrationSpec {
@Autowired
@Shared
private KafkaListenerEndpointRegistry registry
def setupSpec() {
registry.start()
}
def cleanupSpec() {
registry.stop() //to prevent accepting messages from new tests by old context while shutting dow
}
...
}

View Slide

Injecting Spring beans into @Shared ﬁles - limitations
experimental, opt-in feature might not work in all cases
e.g. with @DirtiesContext before/after each test method

View Slide

Injecting Spring beans into @Shared ﬁles - limitations
experimental, opt-in feature might not work in all cases
e.g. with @DirtiesContext before/after each test method
2.0-M
5
2.0-M
5

View Slide

More in Spock 2.0
Java 8 - minimal supported version
new @PendingFeatureIf extension
better error reporting on misused stubs/mocks/spies
easier returning stubbed value for Mock/Spy with subscriber.receive(_) >> _
local extensions can be applied multiple times (e.g. @Requires)
new native @TempDir extension (a replacement for @TemporaryFolder from junit4)
new utility class MutableClock (for time manipulation)
enforce execution with unsupported Groovy version (e.g. 4.0-beta)
Hamcrest upgraded to 2.2 (from 1.3 provided by junit4.jar)

View Slide

Spock 2.1, 2.2 and beyond

View Slide

Spock - oﬃcial logo

View Slide

no oﬃcial logo as of 2.0
problematic in social media, blogs, press releases
several bottom-up proposal over time

View Slide

2.1 - the wait is over!

View Slide

created through many iterations by Ayşe Altınsoy

View Slide

created through many iterations by Ayşe Altınsoy
2.1
2.1

View Slide

Shorten names in iteration reporting

View Slide

tests unrolled by default, but feature name repeated in every iteration
usually not very useful, could require vertical scrolling

View Slide

can be disabled with includeFeatureNameForIterations false in global unroll {}

View Slide

beware, some reporting tools might not (yet) render results as tree

View Slide

beware, some reporting tools might not (yet) render results as tree
2.1
2.1

View Slide

Collection conditions
two new dedicated operators for unordered collection assertion

View Slide

=~ - lenient match - at least one occurrence of every elements in any order
col1 =~ col2
equivalent of more noisy col1 as Set == col2 as Set

View Slide

col1 =~ col2
==~ - strict match - exactly the same elements in any order
col1 ==~ col2
equivalent of containsInAnyOrder() from Hamcrest

View Slide

col1 =~ col2
==~ - strict match - exactly the same elements in any order
col1 ==~ col2
equivalent of containsInAnyOrder() from Hamcrest
2.1
2.1

View Slide

Spock 2.1 - other changes
Add support for selecting individual iterations via their unique ID
dedicated IDE support required (work-in-progress in IDEA)
optional reason to @Requires and @IgnoreIf
support for calling static methods from @IgnoreIf, @Requires and @PendingFeatureIf
used on a specification
improved support for iteration variables with data. prefix
shared fields support (via shared.) in PreconditionContext (conditional test execution)
CI regression testing with JDK 17 (for Groovy 3 variant)

View Slide

Spock 2.2-M1 - Groovy 4.0 support
oﬃcial Groovy 4.0 support
dedicated Spock variant (-groovy-4.0)

View Slide

already possible in Spock 2.0 and 2.1
with -Dspock.iKnowWhatImDoing.disableGroovyVersionCheck=true
but with some corner cases
.

View Slide

.
2.2-M
1
2.2-M
1

View Slide

.
2.2 is still work-in-progress
more changes possible before 2.2-ﬁnal
2.2-M
1
2.2-M
1

View Slide

Migration and summary

View Slide

Migration
bump Spock artifacts version
should work in many cases

View Slide

Migration
bump Spock artifacts version
should work in many cases
switch to Groovy 3, if possible
Java 8 syntax available (e.g. lambda expressions)
no prevailing illegal access warnings
better Java 12+ support

View Slide

Migration - ctd.
if needed
add missing Groovy dependencies (usually groovy-json or groovy-sql)

View Slide

Migration - ctd.
if needed
add org.spockframework:spock-junit4 for @Rule from JUnit 4 support
migrate to native Spock counterparts if available (e.g. @TempDir)

View Slide

Migration - ctd.
if needed
tweak unrolled methods, e.g.
remove @Unroll if not used to override the message
rename #iterationCount to #iterationIndex if used anywhere

View Slide

Migration - ctd.
if needed
tweak unrolled methods, e.g.
remove @Unroll if not used to override the message
rename #iterationCount to #iterationIndex if used anywhere
change data variables referring other variables
where: ----→ where:
a << [1, 2] a << [1, 2]
b << a b = a

View Slide

Key reasons to migrate

View Slide

joining modern JUnit 5 ecosystem
with all its beneﬁts

View Slide

Groovy 3 support
better interoperability with Java code (lambda expressions, ...)

View Slide

Groovy 3 support
better support for modern Java (12+)
with Groovy 3+ - no "illegal access" warnings
with updated conditional test execution (@Requires/@IgnoreIf)

View Slide

Groovy 3 support
Groovy 4 support
oﬃcial support for JDK 17 with records, sealed types, macro methods, ...

View Slide

Groovy 3 support
Groovy 4 support
oﬃcial support for JDK 17 with records, sealed types, macro methods, ...
using supported version of Spock
bugﬁxes and new features
there is no plan to release any new 1.x version

View Slide

Postponed changes

View Slide

Postponed changes
data driven speciﬁcation (parameterized whole test class)
oﬃcial logo - available as of 2.1

View Slide

Summary

View Slide

Summary
testing (ﬁnally) becomes standard practice in 202x

View Slide

Summary
not writing tests is (usually) considered as "faux pas"

View Slide

Summary
still its quality (and quantity) could be higher

View Slide

Summary
nice tools in Java/JVM ecosystem to help

View Slide

Summary
Spock 2 - continually - blazes a trail in simplicity, readability and ﬂexibility

View Slide

Summary
Spock 2 - continually - blazes a trail in simplicity, readability and ﬂexibility
migrate necessarily if stuck with 1.3

View Slide

Thank you!
(and remember about the feedback)
https://blog.solidsoft.pl/
@SolidSoftBlog
[email protected]
OpenPGP: 0x48A84C5100F47FB6
06FA 6793 8DD1 7603 B007 5522 48A8 4C51 00F4 7FB6

View Slide

Questions?
(and remember about the feedback)
https://blog.solidsoft.pl/
@SolidSoftBlog
[email protected]
OpenPGP: 0x48A84C5100F47FB6
06FA 6793 8DD1 7603 B007 5522 48A8 4C51 00F4 7FB6

View Slide

What you can expect from Spock 2?

What you can expect from Spock 2?

Marcin Zajączkowski

More Decks by Marcin Zajączkowski

Other Decks in Programming

Featured

Transcript