The Enterprise-ready testing and specification framework.

Overview

License Maven Central Build Jitpack Codecov Gitter Revved up by Gradle Enterprise

Spock Framework

Spock is a BDD-style developer testing and specification framework for Java and Groovy applications. To learn more about Spock, visit http://spockframework.org. To run a sample spec in your browser, go to http://webconsole.spockframework.org.

Latest Versions

  • The latest 1.x release version is 1.3 (1.3-groovy-2.4, 1.3-groovy-2.5), released on 2019-01-22.
  • The latest 2.0 release version is 2.0-M4 (2.0-M4-groovy-2.5, 2.0-M4-groovy-3.0), released on 2020-11-01.
  • The current development version is 2.0-SNAPSHOT (2.0-groovy-2.5-SNAPSHOT, 2.0-groovy-3.0-SNAPSHOT).

NOTE: Spock 1.3 is the last release for 1.x based on JUnit 4. Spock 2.0 is based on the JUnit 5 Platform and require Java 8/groovy-2.5

Releases are available from Maven Central. Development snapshots are available from Sonatype OSS.

Ad-Hoc Intermediate Releases

For intermediate stable builds we recommend to use Jitpack (go here for instructions):

  1. Add https://jitpack.io as a repository
  2. Use org.spockframework.spock as groupId and the normal artifact-id
repositories {
    // ...
    maven { url 'https://jitpack.io' }
}

dependencies {
        compile 'org.spockframework.spock:spock-core:spock-1.3'
        compile 'org.spockframework.spock:spock-spring:spock-1.3'
}
  1. For intermediate releases you can also use the commit-hash as version, e.g. compile com.github.spockframework.spock:spock-core:d91bf785a1

Modules

  • spock-core -- Core framework. This is the only mandatory module.
  • spock-specs -- Specifications for spock-core, implemented using Spock. Not required for using Spock.
  • spock-spring -- Integration with the Spring TestContext Framework.
  • spock-tapestry -- Integration with the Tapestry 5 IoC container.
  • spock-guice -- Integration with Guice 2/3.
  • spock-unitils -- Integration with Unitils.
  • spock-report -- Interactive, business-friendly HTML reports.

Building

Supported versions

Spock is supported for Java version 7, and 8 (with Groovy 2.5 Java 9+ are supported as well).

Spock is supported for Groovy version 2.4+

The tests are testing spock with a specific versions (variants) of groovy. Default is groovy version 2.4

The groovy 2.4 and 2.5 variant should pass on all supported JDK versions:

./gradlew clean build

(Windows: gradlew clean build). All build dependencies, including the build tool itself, will be downloaded automatically (unless already present).

Contributing

Contributions are welcome! Please see the contributing page for detailed instructions.

Support

If you have any comments or questions, please direct them to the user forum. All feedback is appreciated!

Java 9 Module Names

All published jars (beginning with Spock 1.2) will contain Automatic-Module-Name manifest attribute. This allows for Spock to be used in a Java 9 Module Path.

  • spock-core -- org.spockframework.core
  • spock-spring -- org.spockframework.spring
  • spock-tapestry -- org.spockframework.tapestry
  • spock-guice -- org.spockframework.guice
  • spock-unitils -- org.spockframework.unitils

So module authors can use well known module names for the spock modules, e.g. something like this:

open module foo.bar {
  requires org.spockframework.core;
  requires org.spockframework.spring;
}

Links

Live Long And Prosper!

The Spock Framework Team

Comments
  • Support for Groovy 3.0.0-beta-1

    Support for Groovy 3.0.0-beta-1

    3.0.0-beta-1 has been released: https://lists.apache.org/thread.html/940376461a6a9fae67a177944f3cff07e284465defc09f1229ca60e7@%3Cdev.groovy.apache.org%3E

    opened by henrik242 38
  • Spring Boot 1.4 @WebMvcTest support

    Spring Boot 1.4 @WebMvcTest support

    Support for @SpringTest has been added as part of #581 , however this only provides basic functionality and does not allow to utilise the power of Spring Boot 1.4 and it's testing enhancements in a complete way.

    Basic Web MVC Test for a controller without any dependencies that need to be @Autowired will go through. Spring framework 4.3 provides constructor injection enhancements and even prior to 4.3 it's recommended to use constructor injection for component dependencies. @WebMvcTest when used with JUnit/Mockito empowers developer to automatically inject mock beans with help of new @MockBean annotation.

    This naturally does not work with Spock and mocks created via Spocks Mock() are not injected into the constructor as dependencies, making it much harder to work with Spring Boot and Web MVC Tests.

    opened by alexejk 38
  • Run tests in parallel

    Run tests in parallel

    Originally reported on Google Code with ID 34

    I have an enhancement request to make tests run in parallel. I like Spock
    so much, I'm using it to run some validation tests that run over a large
    dataset. I use the data provider way and @Unroll to run the tests as unique
    tests. They work great, except they run serially and I'd like to use up all
    the cores that the machine has (> 4).
    

    Reported by senthilvasan on 2009-07-17 21:42:40

    Type-Enhancement Module-Core 
    opened by robfletcher 37
  • Support for parallel feature and iteration execution

    Support for parallel feature and iteration execution

    This is clone of #67, rebased on spockframework/master. Difference to #67:

    1. Added test AllTestsInParallelTest."all spock-spec tests in parallel mode". This test runs most tests under org.spockframework package with concurrent sheduler.
    2. Several tests was rewritten to support concurrent execution of tests and iterations.
    3. MockInstantiator now uses ObjenesisStd without cache (cache works only by class name and therefore prevents mocking classes with same name but different classloaders)
    4. Timeouts in TimeoutExtension spec was enlarged to support slower execution of individual test in concurrent mode.
    opened by Fuud 32
  • Cannot create mock due to module java.base does not

    Cannot create mock due to module java.base does not "opens java.lang.invoke"

    Describe the bug

    org.spockframework.mock.runtime.DefaultMethodInvoker is accessing java.lang.invoke.MethodHandles$Lookup.IMPL_LOOKUP which fails with:

    org.spockframework.mock.CannotCreateMockException: Cannot create mock for class jdk.proxy2.$Proxy25Failed to invoke default method 'someDefaultMethod'
    
    	at org.spockframework.mock.runtime.DefaultMethodInvoker.respond(DefaultMethodInvoker.java:64)
    	at org.spockframework.mock.runtime.MockInvocation.callRealMethod(MockInvocation.java:59)
    	at org.spockframework.mock.CallRealMethodResponse.respond(CallRealMethodResponse.java:30)
    	at org.spockframework.mock.runtime.MockController.handle(MockController.java:50)
    	at org.spockframework.mock.runtime.JavaMockInterceptor.intercept(JavaMockInterceptor.java:84)
    	at org.spockframework.mock.runtime.DynamicProxyMockInterceptorAdapter.invoke(DynamicProxyMockInterceptorAdapter.java:34)
    Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field static final java.lang.invoke.MethodHandles$Lookup java.lang.invoke.MethodHandles$Lookup.IMPL_LOOKUP accessible: module java.base does not "opens java.lang.invoke" to unnamed module @3d99d22e
    	at org.spockframework.mock.runtime.DefaultMethodInvoker.respond(DefaultMethodInvoker.java:50)
    	... 7 more
    

    To Reproduce

    This is a minimal reproducible example minimal-reproducible-example.zip

    Expected behavior

    The code should not fail.

    Actual behavior

    The code fails with the given exception.

    Java version

    openjdk version "17.0.1" 2021-10-19 LTS OpenJDK Runtime Environment Corretto-17.0.1.12.1 (build 17.0.1+12-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.1.12.1 (build 17.0.1+12-LTS, mixed mode, sharing) (and probably Java 16)

    Buildtool version

    Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) Maven home: /Users/user/.sdkman/candidates/maven/current Java version: 17.0.1, vendor: Amazon.com Inc., runtime: /Users/user/.sdkman/candidates/java/17.0.1.12.1-amzn Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"

    What operating system are you using

    Mac

    Dependencies

    com.example:demo:jar:0.0.1-SNAPSHOT
    +- org.springframework.boot:spring-boot-starter:jar:2.6.2:compile
    |  +- org.springframework.boot:spring-boot:jar:2.6.2:compile
    |  |  \- org.springframework:spring-context:jar:5.3.14:compile
    |  |     +- org.springframework:spring-aop:jar:5.3.14:compile
    |  |     +- org.springframework:spring-beans:jar:5.3.14:compile
    |  |     \- org.springframework:spring-expression:jar:5.3.14:compile
    |  +- org.springframework.boot:spring-boot-autoconfigure:jar:2.6.2:compile
    |  +- org.springframework.boot:spring-boot-starter-logging:jar:2.6.2:compile
    |  |  +- ch.qos.logback:logback-classic:jar:1.2.9:compile
    |  |  |  \- ch.qos.logback:logback-core:jar:1.2.9:compile
    |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.17.0:compile
    |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.17.0:compile
    |  |  \- org.slf4j:jul-to-slf4j:jar:1.7.32:compile
    |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile
    |  +- org.springframework:spring-core:jar:5.3.14:compile
    |  |  \- org.springframework:spring-jcl:jar:5.3.14:compile
    |  \- org.yaml:snakeyaml:jar:1.29:compile
    +- org.springframework.boot:spring-boot-starter-test:jar:2.6.2:test
    |  +- org.springframework.boot:spring-boot-test:jar:2.6.2:test
    |  +- org.springframework.boot:spring-boot-test-autoconfigure:jar:2.6.2:test
    |  +- com.jayway.jsonpath:json-path:jar:2.6.0:test
    |  |  +- net.minidev:json-smart:jar:2.4.7:test
    |  |  |  \- net.minidev:accessors-smart:jar:2.4.7:test
    |  |  |     \- org.ow2.asm:asm:jar:9.1:test
    |  |  \- org.slf4j:slf4j-api:jar:1.7.32:compile
    |  +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3:test
    |  |  \- jakarta.activation:jakarta.activation-api:jar:1.2.2:test
    |  +- org.assertj:assertj-core:jar:3.21.0:test
    |  +- org.hamcrest:hamcrest:jar:2.2:test
    |  +- org.junit.jupiter:junit-jupiter:jar:5.8.2:test
    |  |  +- org.junit.jupiter:junit-jupiter-api:jar:5.8.2:test
    |  |  |  +- org.opentest4j:opentest4j:jar:1.2.0:test
    |  |  |  +- org.junit.platform:junit-platform-commons:jar:1.8.2:test
    |  |  |  \- org.apiguardian:apiguardian-api:jar:1.1.2:test
    |  |  \- org.junit.jupiter:junit-jupiter-params:jar:5.8.2:test
    |  +- org.mockito:mockito-core:jar:4.0.0:test
    |  |  +- net.bytebuddy:byte-buddy:jar:1.11.22:test
    |  |  +- net.bytebuddy:byte-buddy-agent:jar:1.11.22:test
    |  |  \- org.objenesis:objenesis:jar:3.2:test
    |  +- org.mockito:mockito-junit-jupiter:jar:4.0.0:test
    |  +- org.skyscreamer:jsonassert:jar:1.5.0:test
    |  |  \- com.vaadin.external.google:android-json:jar:0.0.20131108.vaadin1:test
    |  +- org.springframework:spring-test:jar:5.3.14:test
    |  \- org.xmlunit:xmlunit-core:jar:2.8.4:test
    +- org.spockframework:spock-spring:jar:2.1-M2-groovy-3.0:test
    |  +- org.spockframework:spock-core:jar:2.1-M2-groovy-3.0:test
    |  |  \- org.junit.platform:junit-platform-engine:jar:1.8.2:test
    |  \- org.codehaus.groovy:groovy:jar:3.0.9:test
    +- org.codehaus.groovy:groovy-json:jar:3.0.9:test
    \- org.codehaus.groovy:groovy-xml:jar:3.0.9:test
    

    Additional context

    Spock users can solve the issue by adding the following to the pom.xml:

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
            <argLine>
                --add-opens=java.base/java.lang.invoke=ALL-UNNAMED
            </argLine>
        </configuration>
    </plugin>
    

    But I guess a permanent fix would be nice in the library.

    bug 
    opened by akefirad 29
  • Enable usage of Spring beans in @Shared fields, setupSpec() and cleanupSpec()

    Enable usage of Spring beans in @Shared fields, setupSpec() and cleanupSpec()

    It would be absolutely great, if Spring's TestContext framework can be extended, so that Spring beans can be injected in @Shared fields and can be used in setupSpec() and cleanupSpec().

    Thanks, Leif

    enhancement 
    opened by leifhanack 29
  • Filtering by tags in JUnit 5 prevents Spock specs from being executed

    Filtering by tags in JUnit 5 prevents Spock specs from being executed

    Description

    This comes from Junit's EngineDiscoveryOrchestrator

    Screenshot_20210305_175214

    I think this clearly shows there is a bug. Tags should not affect other engines than Jupiter.

    How to reproduce

    Add some Spock 1.x Specs and have a gradle test task configured as follows:

        test {
                useJUnitPlatform {
                    includeTags("SomeTag")
                    includeEngines("junit-vintage")
                }
        }
    

    Observe specs are not being executed. If you comment out the line with "includeTags" the specs are executed.

    I've checked in the debugger that a RunnerTestDescriptor with a Sputnik runner is being discovered (the Specs are not being skipped/ignored by Spock). Screenshot_20210305_165810

    The same happens with Spock 2.x

        test {
                useJUnitPlatform {
                    includeTags("SomeTag")
                    excludeEngines("junit-vintage")
                }
        }
    

    Screenshot_20210305_174750

    Also reported as https://github.com/junit-team/junit5/issues/2563

    Additional Environment information

    • Build Tool/IDE: gradle 6.8.3
    • Spock 1.3-groovy-2.5, 2.0-M2-groovy-2.5
    • JUnit / Platform: 5.6.3 / 1.6.3
    opened by jakub-bochenski 26
  • Field of type Specification loses setupSpec method when used inside another Specification

    Field of type Specification loses setupSpec method when used inside another Specification

    I have a Specification that uses another Specification in a field. I try to call the setupSpec method on it, and it's apparently missing.

    Here's an example:

    import spock.lang.Specification
    
    abstract class Base extends Specification {
        def setupSpec() {}
    }
    
    final class BaseImpl extends Base {
    
    }
    
    class Impl extends Specification {
        Base base = new BaseImpl()
    
        def 'test'() {
            when:
            base.setupSpec()
            then:
            noExceptionThrown()
        }
    }
    

    This spec fails due to:

    Expected no exception to be thrown, but got 'groovy.lang.MissingMethodException'
    	at spock.lang.Specification.noExceptionThrown(Specification.java:118)
    	at bar.Impl.test(Foo.groovy:21)
    Caused by: groovy.lang.MissingMethodException: No signature of method: bar.BaseImpl.setupSpec() is applicable for argument types: () values: []
    	at bar.Impl.test(Foo.groovy:19)
    

    If I instantiate the Base type directly after making it non-abstract, then it works fine.

    I know this is weird, but looks like a bug to me... is there any reason I can't use a Specification field and call its methods like this?

    Tested with Spock 1.3-groovy-2.5 and 2.0-groovy-3.0 and the result is the same.

    not a bug 
    opened by renatoathaydes 25
  • Added support for mock class creation using Byte Buddy

    Added support for mock class creation using Byte Buddy

    Adds support for generating classes using Byte Buddy instead of cglib when Byte Buddy is found on the class path. (Other than on AppVeyor, running :spock-specs:test works fine on my machine.)

    opened by raphw 23
  • interactions in given/setup blocks should have precedence over those in setup methods

    interactions in given/setup blocks should have precedence over those in setup methods

    Originally reported on Google Code with ID 199

    Describe the enhancement you have in mind.
    
    interactions in given/setup blocks should have precedence over those in setup methods
    as discussed in: http://groups.google.com/group/spockframework/browse_thread/thread/3e20f7466dd6248b
    
    Is it possible to override the behaviour (return value) for one
    specific test method: see example below (also available at:
    http://meetspock.appspot.com/script/36001)
    "testing exceptional behaviour" fails where I want it to succeed
    
    interface MyInterface {
        int myMethod()
    
    }
    
    class MyInterfaceTest extends Specification {
        def myInterface = Mock(MyInterface)
    
        def setup() {
            myInterface.myMethod() >> 1
        }
    
        def "testing regular behaviour"() {
            when:
             def result = myInterface.myMethod()
            then:
             result == 1
         }
    
        def "testing exceptional behaviour"() {
            given:
             myInterface.myMethod() >> 2
            when:
             def result = myInterface.myMethod()
            then:
             result == 2
          } 
    }
    
    Which particular problem would this enhancement solve for you?
    it would ease the setup of testing expetional behaviour, where for all other tests
    use the same 'normal' behaviour of the mock, so you don't have to setup this for each
    test.
    
    
    Please provide any additional information below. You can also assign
    labels.
    
    

    Reported by frederic.pape on 2011-09-13 11:08:13

    Type-Enhancement Module-Core 
    opened by robfletcher 23
  • InjectMocks - Property, Setter, Constructor injection

    InjectMocks - Property, Setter, Constructor injection

    1. We stick to creating mocks in the standard Spock way
    2. The objects (not only mocks) that should be injected will be annotated with @Collaborator
    3. The object that should have the dependencies injected into will be called @Subject
    4. The injection takes place as in Mockito (http://docs.mockito.googlecode.com/hg/latest/org/mockito/InjectMocks.html)

    Mockito will try to inject mocks only either by constructor injection, setter injection, or property injection in order and as described below. If any of the following strategy fail, then Mockito won't report failure; i.e. you will have to provide dependencies yourself.

    Constructor injection; the biggest constructor is chosen, then arguments are resolved with mocks declared in the test only. Note: If arguments can not be found, then null is passed. If non-mockable types are wanted, then constructor injection won't happen. In these cases, you will have to satisfy dependencies yourself.

    Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name. Note 1: If you have properties with the same type (or same erasure), it's better to name all @Mock annotated fields with the matching properties, otherwise Mockito might get confused and injection won't happen.

    Note 2: If @InjectMocks instance wasn't initialized before and have a no-arg constructor, then it will be initialized with this constructor.

    Field injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the field name and the mock name. Note 1: If you have fields with the same type (or same erasure), it's better to name all @Mock annotated fields with the matching fields, otherwise Mockito might get confused and injection won't happen.

    Note 2: If @InjectMocks instance wasn't initialized before and have a no-arg constructor, then it will be initialized with this constructor.

    1. At least one element is annotated with Collaborator - we inject only those elements
    2. There is no element annotated with Collaborator - all properties are considered for injections
    opened by marcingrzejszczak 20
  • Bump com.gradle.enterprise from 3.11.2 to 3.12.1

    Bump com.gradle.enterprise from 3.11.2 to 3.12.1

    Bumps com.gradle.enterprise from 3.11.2 to 3.12.1.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Bump org.gradle.test-retry from 1.4.1 to 1.5.0

    Bump org.gradle.test-retry from 1.4.1 to 1.5.0

    Bumps org.gradle.test-retry from 1.4.1 to 1.5.0.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • Bump biz.aQute.bnd.builder from 6.3.1 to 6.4.0

    Bump biz.aQute.bnd.builder from 6.3.1 to 6.4.0

    Bumps biz.aQute.bnd.builder from 6.3.1 to 6.4.0.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 0
  • `FeatureMetadata#dataVariableNames()` has no default or `SpecAnnotator#addFeatureMetadata` does not add attribute value for it

    `FeatureMetadata#dataVariableNames()` has no default or `SpecAnnotator#addFeatureMetadata` does not add attribute value for it

    Describe the bug

    As noted in the title, the annotation attribute population is incomplete for FeatureMetadata. I am in process of fixing GROOVY-10862 which stops setting annotation default value for each and every MethodNode and spock's FeatureMetadata now gives error:

    No explicit/default value found for annotation attribute 'dataVariableNames' in @org.spockframework.runtime.model.FeatureMetadata
    

    To Reproduce

                @Grab('org.spockframework:spock-core:2.4-M1-groovy-4.0')
                @GrabExclude('org.apache.groovy:*')
                import spock.lang.Specification
    
                trait T {
                    def m(Class<?> clazz, Object... array) {
                        clazz.name + array
                    }
                }
    
                class C extends Specification implements T {
                    void test() {
                      when:
                        String result = m(Object,'x')
                      then:
                        result == 'java.lang.Object[x]'
                    }
                }
    
                org.junit.runner.JUnitCore.runClasses(C)
    

    Expected behavior

    Test should run as before.

    Actual behavior

    Error for missing annotation attribute value or default.

    Java version

    N/A

    Buildtool version

    N/A

    What operating system are you using

    Windows

    Dependencies

    N/A

    Additional context

    No response

    bug 
    opened by eric-milles 1
  • Method invocation count breaks when debugging in Java

    Method invocation count breaks when debugging in Java

    Describe the bug

    When breakpoints are triggered using a Java debugger the method invocation count becomes broken.

    To Reproduce

    Running the following without a debugger attached passes:

        def "test"() {
            given:
            def myItem = Mock(Object)
            def myList = new ArrayList()
            myList.add(myItem)
    
            when:
            myList.toString()
    
            then:
            1 * myItem.toString()
            noExceptionThrown()
        }
    

    However, running the code with a debugger attached, with breakpoints at each line, fails returning the following:

    Too many invocations for:

    1 * myItem.toString() (2 invocations)

    Matching invocations (ordered by last occurrence):

    2 * myItem.toString() <-- this triggered the error

    Expected behavior

    The test to pass when both debugging and not debugging.

    Actual behavior

    The test fails.

    Java version

    $ java -version openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

    Buildtool version

    $ mvn --version Apache Maven 3.8.1

    What operating system are you using

    Windows

    Dependencies

    ... +- org.spockframework:spock-core:jar:2.1-groovy-3.0:test | - org.junit.platform:junit-platform-engine:jar:1.8.2:test | +- org.opentest4j:opentest4j:jar:1.2.0:test | +- org.junit.platform:junit-platform-commons:jar:1.8.2:test | - org.apiguardian:apiguardian-api:jar:1.1.2:test +- org.spockframework:spock-spring:jar:2.1-groovy-3.0:test ... +- org.codehaus.groovy:groovy:jar:3.0.12:test - org.codehaus.groovy:groovy-sql:jar:3.0.12:test

    Additional context

    I attached the debugger using the IntelliJ debug tool. The debug command:

    -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:<port>,suspend=y,server=n -javaagent:<path>/IntelliJIdea2022.2/captureAgent/debugger-agent.jar
    

    IntelliJ version:

    IntelliJ IDEA 2022.2.3 (Ultimate Edition)

    pom.xml plugin config:

                <plugin>
                    <!-- gmavenplus plugin is used to compile Groovy code -->
                    <groupId>org.codehaus.gmavenplus</groupId>
                    <artifactId>gmavenplus-plugin</artifactId>
                    <version>1.13.1</version>
                    <executions>
                        <execution>
                            <goals>
                                <goal>addTestSources</goal>
                                <goal>compile</goal>
                                <goal>compileTests</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
    
    bug 
    opened by JCass149 3
  • Multiple

    Multiple "when" block for single "then" block

    Is your feature request related to a problem?

    I have a lot of situations and I can't find my problem solution in documentation.

    The problem is: I have a lot of tests where I expect the same errors and data with similar, or the same given data. In these situations I have everywhere the same given and then blocks for each when block (when is ussualy invoking one method). In these situations I have a lot of boilerplate in test code which is not readable.

    Describe the solution you'd like

    I tried to use where block and give Clousure, or Runnable, then invoke it in when block, but iI got "Groovyc: Header of data table may only contain variable names"

    The best in use will be multiple when: labels for every tested method

    In documentation I found only multiple when: then:, but multiple when: for the same then: is needed.

    Do you have some idea?

    Describe alternatives you've considered

    No response

    Additional context

    No response

    new feature 
    opened by lowcasz 0
Releases(spock-2.4-M1)
Java testing framework for testing pojo methods

Java testing framework for testing pojo methods. It tests equals, hashCode, toString, getters, setters, constructors and whatever you report in issues ;)

Piotr Joński 48 Aug 23, 2022
Java library for the Siren Hypermedia Type Specification

This is a java library to help with the creation and use of Hypermedia entities as specified by the Siren hypermedia specification. See https://github

Erik Serating 23 May 8, 2022
Ready-to-use UI Test Automation Architecture using Java and Selenium WebDriver.

Selenium Test Automation Boilerplate Ready-to-use UI Test Automation Architecture using Java and Selenium WebDriver. Languages and Frameworks The proj

Tahanima Chowdhury 133 Dec 26, 2022
Layout and functional testing framework for websites

Galen Framework master: Galen is an open-source tool for testing layout and responsive design of web applications. It is also a powerfull functional t

Galen Framework 1.4k Dec 10, 2022
A programmer-oriented testing framework for Java.

JUnit 4 JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. For more infor

JUnit 8.4k Jan 4, 2023
TestNG testing framework

Documentation available at TestNG's main web site. Release Notes 7.4.0 7.3.0 7.1.0 7.0.0 Need help? Before opening a new issue, did you ask your quest

Cedric Beust 1.8k Jan 5, 2023
JVM version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.

pact-jvm JVM implementation of the consumer driven contract library pact. From the Ruby Pact website: Define a pact between service consumers and prov

Pact Foundation 962 Dec 31, 2022
Toolkit for testing multi-threaded and asynchronous applications

ConcurrentUnit A simple, zero-dependency toolkit for testing multi-threaded code. Supports Java 1.6+. Introduction ConcurrentUnit was created to help

Jonathan Halterman 406 Dec 30, 2022
Advanced Java library for integration testing, mocking, faking, and code coverage

Codebase for JMockit 1.x releases - Documentation - Release notes How to build the project: use JDK 1.8 or newer use Maven 3.6.0 or newer; the followi

The JMockit Testing Toolkit 439 Dec 9, 2022
ScalaTest is a free, open-source testing toolkit for Scala and Java programmers

ScalaTest is a free, open-source testing toolkit for Scala and Java programmers.

ScalaTest 1.1k Dec 26, 2022
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 6.2k Dec 31, 2022
Cucumber DSL for testing RESTful Web Services

cukes-rest takes simplicity of Cucumber and provides bindings for HTTP specification. As a sugar on top, cukes-rest adds steps for storing and using r

C.T.Co 100 Oct 18, 2022
Randomized Testing (Core JUnit Runner, ANT, Maven)

RANDOMIZED TESTING ================== JUnit test runner and plugins for running JUnit tests with pseudo-randomness. See the following for more infor

null 167 Dec 26, 2022
Captures log entries for unit testing purposes

LogCaptor Install with maven <dependency> <groupId>io.github.hakky54</groupId> <artifactId>logcaptor</artifactId> <version>2.4.0</version>

null 215 Jan 1, 2023
Java DSL for easy testing of REST services

Testing and validation of REST services in Java is harder than in dynamic languages such as Ruby and Groovy. REST Assured brings the simplicity of usi

REST Assured 6.2k Dec 25, 2022
🎉Back end module of Sonic UI automation testing platform. Sonic-UI自动化测试平台后端模块。

?? Sonic UI automation testing platform. English | 简体中文 Background What is sonic ? Nowadays, automation testing, remote control and other technologies

Eason 1.7k Jan 1, 2023
JVM version of Pact Enables consumer driven contract testing

JVM version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.

Pact Foundation 961 Dec 30, 2022
State of the art mutation testing system for the JVM

Pitest (aka PIT) is a state of the art mutation testing system for Java and the JVM. Read all about it at http://pitest.org Releases 1.7.3 #952 Mutate

Henry Coles 1.5k Dec 26, 2022