Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What you can expect from Spock 2?

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.

Marcin Zajączkowski

June 25, 2022
Tweet

More Decks by Marcin Zajączkowski

Other Decks in Programming

Transcript

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

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

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

    View Slide

  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/

    View Slide

  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

    View Slide

  39. 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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

  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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

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

    View Slide

  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/

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  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/

    View Slide

  100. 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/

    View Slide

  101. 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/

    View Slide