Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Presentation goal Make you familiar with "new and noteworthy" in Spock 2 (and encourage to migration) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 3

Slide 3 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 4

Slide 4 text

Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 5

Slide 5 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 6

Slide 6 text

State of Spock in 2022 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 7

Slide 7 text

State of Spock in 2022 actively developed new features and bugfixes 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 8

Slide 8 text

Key changes in Spock 2 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 9

Slide 9 text

#1 - JUnit Platform (JUnit 5) as a base Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 10

Slide 10 text

JUnit 5 vs JUnit Platform Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Diagram by Marc Philipp from JUnit team

Slide 11

Slide 11 text

JUnit 5 vs JUnit Platform Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Diagram by Marc Philipp from JUnit team Spock Spock

Slide 12

Slide 12 text

Spock 2 and JUnit 4 Rules Spock 1.x was JUnit 4 Runner (most of) JUnit 4 Rules could be used Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 13

Slide 13 text

Spock 2 and JUnit 4 Rules Spock 1.x was JUnit 4 Runner (most of) JUnit 4 Rules could be used Spock 2.x uses JUnit Platform JUnit 5 doesn't support @Rule anymore * some rules very popular - e.g. @Rule TemporaryFolder Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 14

Slide 14 text

Spock 2 and JUnit 4 Rules Spock 1.x was JUnit 4 Runner (most of) JUnit 4 Rules could be used 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 15

Slide 15 text

#2 - Groovy 3 support Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 16

Slide 16 text

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-final Spock 2.0-M2 released right after Groovy 3.0.0-final just in time as 1.3 and 2.0-M1 had blocked execution with 3.0* Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 17

Slide 17 text

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-final Spock 2.0-M2 released right after Groovy 3.0.0-final just in time as 1.3 and 2.0-M1 had blocked execution with 3.0* . binary artifact variants for -groovy-2.5 and -groovy-3.0 spock-groovy2-compat implicitly added to classpath for Groovy 2 version Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 18

Slide 18 text

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-final Spock 2.0-M2 released right after Groovy 3.0.0-final just in time as 1.3 and 2.0-M1 had blocked execution with 3.0* . binary artifact variants for -groovy-2.5 and -groovy-3.0 spock-groovy2-compat implicitly added to classpath for Groovy 2 version Important. Do not mix spock-*-2.0-groovy.2-5 jars with groovy-core-3.0 jars weird runtime errors might happen Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 19

Slide 19 text

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-final Spock 2.0-M2 released right after Groovy 3.0.0-final just in time as 1.3 and 2.0-M1 had blocked execution with 3.0* . binary artifact variants for -groovy-2.5 and -groovy-3.0 spock-groovy2-compat implicitly added to classpath for Groovy 2 version Important. Do not mix spock-*-2.0-groovy.2-5 jars with groovy-core-3.0 jars weird runtime errors might happen Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.0-M 2 2.0-M 2

Slide 20

Slide 20 text

#3 - Test unrolling by default Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 21

Slide 21 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 22

Slide 22 text

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 @Unroll to alternative display name in test report #placeholder in method name works by default for fields and static methods with no parameter provided: #featureName, #iterationIndex @Rollup for explicitly disabling unrolling at method or test level Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 23

Slide 23 text

Test unrolling by default new default unrolling pattern (must be unique per iteration) e.g. feature name [param1: 123, param2: bar, #0] custom configurable with unroll { defaultPattern ... } configurable 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) } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 24

Slide 24 text

Test unrolling by default new default unrolling pattern (must be unique per iteration) e.g. feature name [param1: 123, param2: bar, #0] custom configurable with unroll { defaultPattern ... } configurable 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) } broken placeholders fail test by default in 1.x only easy to ignore warning possible to disable for interim period with unroll { validateExpressions false } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 25

Slide 25 text

Test unrolling by default new default unrolling pattern (must be unique per iteration) e.g. feature name [param1: 123, param2: bar, #0] custom configurable with unroll { defaultPattern ... } configurable 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) } broken placeholders fail test by default in 1.x only easy to ignore warning possible to disable for interim period with unroll { validateExpressions false } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.0- 2.0- M 1/M 3 M 1/M 3

Slide 26

Slide 26 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 27

Slide 27 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 28

Slide 28 text

#4 - Parallel test execution Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 29

Slide 29 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 30

Slide 30 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 31

Slide 31 text

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 simplified Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 32

Slide 32 text

Parallel test execution - example with locks - simplified @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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 33

Slide 33 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 34

Slide 34 text

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 runner { parallel { enabled true //disabled by default dynamicWithReservedProcessors(1.0, 2) //default value defaultSpecificationExecutionMode ExecutionMode.CONCURRENT //default value defaultExecutionMode ExecutionMode.CONCURRENT //default value } } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 35

Slide 35 text

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 runner { parallel { enabled true //disabled by default dynamicWithReservedProcessors(1.0, 2) //default value defaultSpecificationExecutionMode ExecutionMode.CONCURRENT //default value defaultExecutionMode ExecutionMode.CONCURRENT //default value } } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Still in Still in beta! beta! 2.0-M 4 2.0-M 4

Slide 36

Slide 36 text

Other changes Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 37

Slide 37 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 38

Slide 38 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.0- 2.0- M 2/final M 2/final

Slide 39

Slide 39 text

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} Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 40

Slide 40 text

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}" Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 41

Slide 41 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 42

Slide 42 text

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 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 43

Slide 43 text

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 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Breaking Breaking change change 2.0-M 3 2.0-M 3

Slide 44

Slide 44 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 45

Slide 45 text

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 @Before/@After/... annotations used only if spock-junit4 available considered as deprecated Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 46

Slide 46 text

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 @Before/@After/... annotations used only if spock-junit4 available considered as deprecated changed order of fixture 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 47

Slide 47 text

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 } ... } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 48

Slide 48 text

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 } ... } 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 49

Slide 49 text

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 } ... } 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Breaking Breaking change change 2.0-M 3 2.0-M 3

Slide 50

Slide 50 text

Injecting Spring beans into @Shared files long awaited feature (April 2015) before that only various hacks workarounds were possible Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 51

Slide 51 text

Injecting Spring beans into @Shared files long awaited feature (April 2015) before that only various hacks workarounds were possible @EnableSharedInjection to enable per specification (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 } ... } Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 52

Slide 52 text

Injecting Spring beans into @Shared files - limitations experimental, opt-in feature might not work in all cases e.g. with @DirtiesContext before/after each test method Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 53

Slide 53 text

Injecting Spring beans into @Shared files - limitations experimental, opt-in feature might not work in all cases e.g. with @DirtiesContext before/after each test method Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.0-M 5 2.0-M 5

Slide 54

Slide 54 text

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) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 55

Slide 55 text

Spock 2.1, 2.2 and beyond Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 56

Slide 56 text

Spock - official logo Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 57

Slide 57 text

Spock - official logo no official logo as of 2.0 problematic in social media, blogs, press releases several bottom-up proposal over time Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 58

Slide 58 text

Spock - official logo no official logo as of 2.0 problematic in social media, blogs, press releases several bottom-up proposal over time Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 59

Slide 59 text

Spock - official logo no official logo as of 2.0 problematic in social media, blogs, press releases several bottom-up proposal over time Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 60

Slide 60 text

Spock - official logo no official logo as of 2.0 problematic in social media, blogs, press releases several bottom-up proposal over time Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 61

Slide 61 text

Spock - official logo 2.1 - the wait is over! Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 62

Slide 62 text

Spock - official logo 2.1 - the wait is over! created through many iterations by Ayşe Altınsoy Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 63

Slide 63 text

Spock - official logo 2.1 - the wait is over! created through many iterations by Ayşe Altınsoy Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.1 2.1

Slide 64

Slide 64 text

Shorten names in iteration reporting Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 65

Slide 65 text

Shorten names in iteration reporting tests unrolled by default, but feature name repeated in every iteration usually not very useful, could require vertical scrolling Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 66

Slide 66 text

Shorten names in iteration reporting tests unrolled by default, but feature name repeated in every iteration usually not very useful, could require vertical scrolling can be disabled with includeFeatureNameForIterations false in global unroll {} Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 67

Slide 67 text

Shorten names in iteration reporting tests unrolled by default, but feature name repeated in every iteration usually not very useful, could require vertical scrolling can be disabled with includeFeatureNameForIterations false in global unroll {} beware, some reporting tools might not (yet) render results as tree Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 68

Slide 68 text

Shorten names in iteration reporting tests unrolled by default, but feature name repeated in every iteration usually not very useful, could require vertical scrolling can be disabled with includeFeatureNameForIterations false in global unroll {} beware, some reporting tools might not (yet) render results as tree Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.1 2.1

Slide 69

Slide 69 text

Collection conditions two new dedicated operators for unordered collection assertion Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 70

Slide 70 text

Collection conditions two new dedicated operators for unordered collection assertion =~ - lenient match - at least one occurrence of every elements in any order col1 =~ col2 equivalent of more noisy col1 as Set == col2 as Set Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 71

Slide 71 text

Collection conditions two new dedicated operators for unordered collection assertion =~ - lenient match - at least one occurrence of every elements in any order col1 =~ col2 equivalent of more noisy col1 as Set == col2 as Set ==~ - strict match - exactly the same elements in any order col1 ==~ col2 equivalent of containsInAnyOrder() from Hamcrest Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 72

Slide 72 text

Collection conditions two new dedicated operators for unordered collection assertion =~ - lenient match - at least one occurrence of every elements in any order col1 =~ col2 equivalent of more noisy col1 as Set == col2 as Set ==~ - strict match - exactly the same elements in any order col1 ==~ col2 equivalent of containsInAnyOrder() from Hamcrest Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.1 2.1

Slide 73

Slide 73 text

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) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 74

Slide 74 text

Spock 2.2-M1 - Groovy 4.0 support official Groovy 4.0 support dedicated Spock variant (-groovy-4.0) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 75

Slide 75 text

Spock 2.2-M1 - Groovy 4.0 support official Groovy 4.0 support dedicated Spock variant (-groovy-4.0) already possible in Spock 2.0 and 2.1 with -Dspock.iKnowWhatImDoing.disableGroovyVersionCheck=true but with some corner cases . Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 76

Slide 76 text

Spock 2.2-M1 - Groovy 4.0 support official Groovy 4.0 support dedicated Spock variant (-groovy-4.0) already possible in Spock 2.0 and 2.1 with -Dspock.iKnowWhatImDoing.disableGroovyVersionCheck=true but with some corner cases . Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.2-M 1 2.2-M 1

Slide 77

Slide 77 text

Spock 2.2-M1 - Groovy 4.0 support official Groovy 4.0 support dedicated Spock variant (-groovy-4.0) already possible in Spock 2.0 and 2.1 with -Dspock.iKnowWhatImDoing.disableGroovyVersionCheck=true but with some corner cases . 2.2 is still work-in-progress more changes possible before 2.2-final Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ 2.2-M 1 2.2-M 1

Slide 78

Slide 78 text

Migration and summary Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 79

Slide 79 text

Migration bump Spock artifacts version should work in many cases Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 80

Slide 80 text

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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 81

Slide 81 text

Migration - ctd. if needed add missing Groovy dependencies (usually groovy-json or groovy-sql) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 82

Slide 82 text

Migration - ctd. if needed add missing Groovy dependencies (usually groovy-json or groovy-sql) add org.spockframework:spock-junit4 for @Rule from JUnit 4 support migrate to native Spock counterparts if available (e.g. @TempDir) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 83

Slide 83 text

Migration - ctd. if needed add missing Groovy dependencies (usually groovy-json or groovy-sql) add org.spockframework:spock-junit4 for @Rule from JUnit 4 support migrate to native Spock counterparts if available (e.g. @TempDir) tweak unrolled methods, e.g. remove @Unroll if not used to override the message rename #iterationCount to #iterationIndex if used anywhere Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 84

Slide 84 text

Migration - ctd. if needed add missing Groovy dependencies (usually groovy-json or groovy-sql) add org.spockframework:spock-junit4 for @Rule from JUnit 4 support migrate to native Spock counterparts if available (e.g. @TempDir) 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 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 85

Slide 85 text

Key reasons to migrate Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 86

Slide 86 text

Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 87

Slide 87 text

Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Groovy 3 support better interoperability with Java code (lambda expressions, ...) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 88

Slide 88 text

Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Groovy 3 support better interoperability with Java code (lambda expressions, ...) better support for modern Java (12+) with Groovy 3+ - no "illegal access" warnings with updated conditional test execution (@Requires/@IgnoreIf) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 89

Slide 89 text

Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Groovy 3 support better interoperability with Java code (lambda expressions, ...) better support for modern Java (12+) with Groovy 3+ - no "illegal access" warnings with updated conditional test execution (@Requires/@IgnoreIf) Groovy 4 support official support for JDK 17 with records, sealed types, macro methods, ... Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 90

Slide 90 text

Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Groovy 3 support better interoperability with Java code (lambda expressions, ...) better support for modern Java (12+) with Groovy 3+ - no "illegal access" warnings with updated conditional test execution (@Requires/@IgnoreIf) Groovy 4 support official support for JDK 17 with records, sealed types, macro methods, ... using supported version of Spock bugfixes and new features there is no plan to release any new 1.x version Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 91

Slide 91 text

Postponed changes Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 92

Slide 92 text

Postponed changes data driven specification (parameterized whole test class) official logo - available as of 2.1 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 93

Slide 93 text

Summary Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 94

Slide 94 text

Summary testing (finally) becomes standard practice in 202x Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 95

Slide 95 text

Summary testing (finally) becomes standard practice in 202x not writing tests is (usually) considered as "faux pas" Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 96

Slide 96 text

Summary testing (finally) becomes standard practice in 202x not writing tests is (usually) considered as "faux pas" still its quality (and quantity) could be higher Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 97

Slide 97 text

Summary testing (finally) becomes standard practice in 202x not writing tests is (usually) considered as "faux pas" still its quality (and quantity) could be higher nice tools in Java/JVM ecosystem to help Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 98

Slide 98 text

Summary testing (finally) becomes standard practice in 202x not writing tests is (usually) considered as "faux pas" still its quality (and quantity) could be higher nice tools in Java/JVM ecosystem to help Spock 2 - continually - blazes a trail in simplicity, readability and flexibility Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 99

Slide 99 text

Summary testing (finally) becomes standard practice in 202x not writing tests is (usually) considered as "faux pas" still its quality (and quantity) could be higher nice tools in Java/JVM ecosystem to help Spock 2 - continually - blazes a trail in simplicity, readability and flexibility migrate necessarily if stuck with 1.3 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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