What you can expect from Spock 2?

Spring 2021 - long awaited - Spock 2.0 has been finally released (followed by 2.1 and 2.2). Heavily rewritten to leverage JUnit Platform (a crucial part of JUnit 5) is ready for even better testing in your projects.

However, what about the support for Groovy 3 and Java 14+? Is Spock compatible with a brand new Groovy 4 and Java 17+? Could the parametrized tests be even better? How problematic will it be to migrate existing tests from Spock 1.3 (especially those using JUnit 4's rules)? What other new features and breaking changes are expected in 2.x?

During this talk, I will summarize over 2 years of development, explaining if/how it impacts the status quo (Spock 2 vs JUnit Jupiter 5) presented by me three years ago.

Transcript

1. What you can expect from Spock 2? Marcin Zajączkowski Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Warszawa, 25 June 2022
2. Presentation goal Make you familiar with "new and noteworthy" in Spock 2 (and encourage to migration) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
3. 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/
4. Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
5. 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/
6. State of Spock in 2022 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
7. 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/
8. Key changes in Spock 2 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
9. #1 - JUnit Platform (JUnit 5) as a base Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
10. JUnit 5 vs JUnit Platform Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Diagram by Marc Philipp from JUnit team
11. JUnit 5 vs JUnit Platform Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/ Diagram by Marc Philipp from JUnit team Spock Spock
12. 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/
13. 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/
14. 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/
15. #2 - Groovy 3 support Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
16. 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/
17. 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/
18. 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/
19. 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
20. #3 - Test unrolling by default Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
21. 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/
22. 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/
23. 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/
24. 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/
25. 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
26. 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/
27. 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/
28. #4 - Parallel test execution Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
29. 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/
30. 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/
31. 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/
32. 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/
33. 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/
34. 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/
35. 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
36. Other changes Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
37. 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/
38. 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
39. Reduced Groovy dependencies Groovy 2.0 - groovy.jar + Groovy modules (vs still available groovy-all.jar) possible version clashes - quite common defensive exclusions <dependency> <groupId>org.codehaus.gmaven.runtime</groupId> <artifactId>YYY</artifactId> <version>1.2</version> <exclusions> <exclusion> <groupId>org.codehaus.groovy</groupId> <artifactId>*</artifactId> </exclusion> </exclusions> <dependency/> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>${groovy.version}</version> <dependency/> Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
40. 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/
41. 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/
42. 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/
43. 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
44. 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/
45. 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/
46. 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/
47. 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/
48. 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/
49. 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
50. 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/
51. 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/
52. 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/
53. 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
54. 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/
55. Spock 2.1, 2.2 and beyond Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
56. Spock - official logo Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
57. 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/
58. 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/
59. 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/
60. 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/
61. Spock - official logo 2.1 - the wait is over! Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
62. 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/
63. 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
64. Shorten names in iteration reporting Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
65. 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/
66. 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/
67. 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/
68. 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
69. Collection conditions two new dedicated operators for unordered collection assertion Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
70. 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/
71. 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/
72. 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
73. 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/
74. 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/
75. 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/
76. 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
77. 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
78. Migration and summary Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
79. Migration bump Spock artifacts version should work in many cases Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
80. 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/
81. Migration - ctd. if needed add missing Groovy dependencies (usually groovy-json or groovy-sql) Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
82. 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/
83. 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/
84. 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/
85. Key reasons to migrate Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
86. Key reasons to migrate joining modern JUnit 5 ecosystem with all its benefits Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
87. 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/
88. 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/
89. 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/
90. 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/
91. Postponed changes Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
92. Postponed changes data driven specification (parameterized whole test class) official logo - available as of 2.1 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
93. Summary Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
94. Summary testing (finally) becomes standard practice in 202x Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
95. 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/
96. 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/
97. 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/
98. 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/
99. 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/
100. Thank you! (and remember about the feedback) Marcin Zajączkowski https://blog.solidsoft.pl/ @SolidSoftBlog m.zajaczkowski@gmail.com OpenPGP: 0x48A84C5100F47FB6 06FA 6793 8DD1 7603 B007 5522 48A8 4C51 00F4 7FB6 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/
101. Questions? (and remember about the feedback) Marcin Zajączkowski https://blog.solidsoft.pl/ @SolidSoftBlog m.zajaczkowski@gmail.com OpenPGP: 0x48A84C5100F47FB6 06FA 6793 8DD1 7603 B007 5522 48A8 4C51 00F4 7FB6 Marcin Zajączkowski @SolidSoftBlog https://blog.solidsoft.pl/