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

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.

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

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.

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.

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

Description

This comes from Junit's EngineDiscoveryOrchestrator

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).

The same happens with Spock 2.x

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

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

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.

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.)

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

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.

5. At least one element is annotated with Collaborator - we inject only those elements
6. There is no element annotated with Collaborator - all properties are considered for injections

Bumps com.gradle.enterprise from 3.11.2 to 3.12.1.

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.

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

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.

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

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.

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

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>

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