Spring Boot 4 `wiremock-spring-boot` support for `spock-spring`

[dlehammer]

Describe the bug

Spring has removed @AutoConfigureWireMock support in Spring Cloud 2025.1.0, the Spring Boot 4.0 compatible edition.
@AutoConfigureWireMock previously encapsulated the WireMock setup, transparently supporting utilizing the instance as-is in specs.

Going forward Spring recommends wiremock-spring-boot, unfortunately the replacement @EnableWireMock doesn't work out-of-the-box in Spock 2.4.
Note @EnableWireMock works as advertised in a similar JUnit test.

To Reproduce

I've created a reproducer: https://github.com/dlehammer/spock-wiremock-spring-boot-support-issue that contains the Spring Boot 3.5 starting point and the Spring Boot 4.0 symptom.

The reproducer contains BasicUsageSpec.groovy that demonstrates the symptom and BasicUsageTests.java that demonstrates the JUnit support.

Expected behavior

• Workaround can be omitted.
• @InjectWireMock populates the spec field.

Actual behavior

Without the workaround BasicUsageSpec WireMock.stubFor(.. setup fails with

org.apache.hc.client5.http.HttpHostConnectException: Connect to http://localhost:8080 failed: Connection refused
	at java.base@21.0.8/sun.nio.ch.Net.pollConnectNow(Net.java:682)
	at java.base@21.0.8/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:542)
	at java.base@21.0.8/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:592)
	at java.base@21.0.8/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base@21.0.8/java.net.Socket.connect(Socket.java:751)
	at app//org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:215)
	at app//org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:497)
	at app//org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:164)
	at app//org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:174)
	at app//org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:144)
	at app//org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at app//org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:195)
	at app//org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at app//org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at app//org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:123)
	at app//com.github.tomakehurst.wiremock.client.HttpAdminClient.safelyExecuteRequest(HttpAdminClient.java:569)
	at app//com.github.tomakehurst.wiremock.client.HttpAdminClient.executeRequest(HttpAdminClient.java:534)
	at app//com.github.tomakehurst.wiremock.client.HttpAdminClient.executeRequest(HttpAdminClient.java:515)
	at app//com.github.tomakehurst.wiremock.client.HttpAdminClient.addStubMapping(HttpAdminClient.java:173)
	at app//com.github.tomakehurst.wiremock.client.WireMock.register(WireMock.java:496)
	at app//com.github.tomakehurst.wiremock.client.WireMock.register(WireMock.java:491)
	at app//com.github.tomakehurst.wiremock.client.WireMock.givenThat(WireMock.java:134)
	at app//com.github.tomakehurst.wiremock.client.WireMock.stubFor(WireMock.java:138)
	at reproducer.BasicUsageSpec.returns_a_ping(BasicUsageSpec.groovy:34)

With workaround enabled BasicUsageSpec fails with

Condition not satisfied:

wireMockServer
|
null

	at reproducer.BasicUsageSpec.returns_a_ping(BasicUsageSpec.groovy:47)

Java version

$ java -version
openjdk version "21.0.8" 2025-07-15 LTS
OpenJDK Runtime Environment Temurin-21.0.8+9 (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.8+9 (build 21.0.8+9-LTS, mixed mode, sharing)

Buildtool version

$ ./gradlew --version

------------------------------------------------------------
Gradle 9.2.1
------------------------------------------------------------

Build time:    2025-11-17 13:40:48 UTC
Revision:      30ecdc708db275e8f8769ea0620f6dd919a58f76

Kotlin:        2.2.20
Groovy:        4.0.28
Ant:           Apache Ant(TM) version 1.10.15 compiled on August 25 2024
Launcher JVM:  21.0.8 (Eclipse Adoptium 21.0.8+9-LTS)
Daemon JVM:    /home/dlehammer/.sdkman/candidates/java/21.0.8-tem (no JDK specified, using current Java home)
OS:            Linux 6.8.0-90-generic amd64

What operating system are you using

Linux

Dependencies

See reproducer build.gradle for details.

Additional context

No response

[dlehammer]

Hi Spock gurus,

I've been doing some additional digging, attempting to eliminate some unknowns, so here goes.

Utilizing the reproducer I've confirmed the symptom is present in combination with wiremock-spring-boot releases.

• 4.0.3 (first public v4 release)
• 4.0.4
• 4.0.5
• 4.0.6
• 4.0.7
• 4.0.8
• 4.0.9

I've also added BasicUsageGroovyTests.groovy similar to BasicUsageTests.java to the reproducer, which seems to eliminate Groovy as the source of the symptom.

Hopefully this helps narrow down the source of the symptom 🤓

[marcindabrowski]

I was using wiremock-spring-boot with https://github.com/xvik/spock-junit5. It was working with with Spring Boot 3.4 and 3.5.
Didn't check with Spring Boot 4.0.

[marcindabrowski]

And I'm not using default wiremockserver.
Did something like this:

@EnableWireMock([
    @ConfigureWireMock(name = "firstServiceWireMockServer", baseUrlProperties = "my-client.firstService.base-uri"),
    @ConfigureWireMock(name = "secondServiceWireMockServer", baseUrlProperties = "my-client.secondService.base-uri"),
])

...

    @InjectWireMock("firstServiceWireMockServer")
    WireMockServer firstServiceWireMockServer

    @InjectWireMock("secondServiceWireMockServer")
    WireMockServer secondServiceWireMockServer

then you can call firstServiceWireMockServer.stubFor("<only the path without localhost and port>").

And of course your RestClient should be initilaized with my-client.firstService.base-uri value: RestClient.baseUrl(properties.baseUri).build();

[dlehammer]

Hi @marcindabrowski ,

Thank you for your suggestions.

Regarding

Didn't check with Spring Boot 4.0.

I've created a Spring Boot 4 branch chore/spring-boot-4-upgrade+xvik_spock-junit5, based on my interpretation of your suggestion.

Unfortunately this results the following error:

java.lang.AbstractMethodError: Receiver class ru.vyarus.spock.jupiter.engine.store.NamespaceAwareStore does not define or inherit an implementation of the resolved method 'abstract java.lang.Object computeIfAbsent(java.lang.Object, java.util.function.Function, java.lang.Class)' of interface org.junit.jupiter.api.extension.ExtensionContext$Store.
	at org.springframework.test.context.junit.jupiter.SpringExtension.getTestContextManager(SpringExtension.java:429)
	at org.springframework.test.context.junit.jupiter.SpringExtension.beforeAll(SpringExtension.java:172)
	at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$beforeAll$0(JunitApiExecutor.java:53)
	at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.beforeAll(JunitApiExecutor.java:53)
	at ru.vyarus.spock.jupiter.interceptor.ExtensionLifecycleMerger.interceptSetupSpecMethod(ExtensionLifecycleMerger.java:98)
	at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:36)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
	at org.spockframework.spring.SpringInterceptor.interceptSetupSpecMethod(SpringInterceptor.java:40)
	at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:36)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
	at org.spockframework.runtime.model.MethodInfo.invoke(MethodInfo.java:157)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:141)
	at ru.vyarus.spock.jupiter.JunitExtensionSupport.lambda$visitSpec$1(JunitExtensionSupport.java:112)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	Suppressed: java.lang.AbstractMethodError: Receiver class ru.vyarus.spock.jupiter.engine.store.NamespaceAwareStore does not define or inherit an implementation of the resolved method 'abstract java.lang.Object computeIfAbsent(java.lang.Object, java.util.function.Function, java.lang.Class)' of interface org.junit.jupiter.api.extension.ExtensionContext$Store.
		at org.springframework.test.context.junit.jupiter.SpringExtension.getTestContextManager(SpringExtension.java:429)
		at org.springframework.test.context.junit.jupiter.SpringExtension.afterAll(SpringExtension.java:183)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$afterAll$12(JunitApiExecutor.java:123)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$afterAll$13(JunitApiExecutor.java:123)
		at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.afterAll(JunitApiExecutor.java:122)
		at ru.vyarus.spock.jupiter.interceptor.ExtensionLifecycleMerger.interceptCleanupSpecMethod(ExtensionLifecycleMerger.java:180)
		at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:39)
		at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
		at org.spockframework.spring.SpringInterceptor.interceptCleanupSpecMethod(SpringInterceptor.java:87)
		at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:39)
		... 6 more

On top of that I'm not a fan of 3rd party dependencies for support previously provided by the official Spock library.

And I'm not using default wiremockserver.

I would appreciate continuation of the previously supported default WireMock, as that would avoid undesired boiler-plate + allow for upgrades with minimal effort 🤓

[dlehammer]

Note: unfortunately the suggestion from https://github.com/xvik/spock-junit5?tab=readme-ov-file#usage-with-spring-boot regarding replacing spock-spring with spock-core doesn't make a difference.

initializationError:

java.lang.AbstractMethodError: Receiver class ru.vyarus.spock.jupiter.engine.store.NamespaceAwareStore does not define or inherit an implementation of the resolved method 'abstract java.lang.Object computeIfAbsent(java.lang.Object, java.util.function.Function, java.lang.Class)' of interface org.junit.jupiter.api.extension.ExtensionContext$Store.
	at org.springframework.test.context.junit.jupiter.SpringExtension.getTestContextManager(SpringExtension.java:429)
	at org.springframework.test.context.junit.jupiter.SpringExtension.beforeAll(SpringExtension.java:172)
	at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$beforeAll$0(JunitApiExecutor.java:53)
	at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.beforeAll(JunitApiExecutor.java:53)
	at ru.vyarus.spock.jupiter.interceptor.ExtensionLifecycleMerger.interceptSetupSpecMethod(ExtensionLifecycleMerger.java:98)
	at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:36)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
	at org.spockframework.runtime.model.MethodInfo.invoke(MethodInfo.java:157)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:141)
	at ru.vyarus.spock.jupiter.JunitExtensionSupport.lambda$visitSpec$1(JunitExtensionSupport.java:112)
	at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:139)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	Suppressed: java.lang.AbstractMethodError: Receiver class ru.vyarus.spock.jupiter.engine.store.NamespaceAwareStore does not define or inherit an implementation of the resolved method 'abstract java.lang.Object computeIfAbsent(java.lang.Object, java.util.function.Function, java.lang.Class)' of interface org.junit.jupiter.api.extension.ExtensionContext$Store.
		at org.springframework.test.context.junit.jupiter.SpringExtension.getTestContextManager(SpringExtension.java:429)
		at org.springframework.test.context.junit.jupiter.SpringExtension.afterAll(SpringExtension.java:183)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$afterAll$12(JunitApiExecutor.java:123)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.lambda$afterAll$13(JunitApiExecutor.java:123)
		at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
		at ru.vyarus.spock.jupiter.interceptor.JunitApiExecutor.afterAll(JunitApiExecutor.java:122)
		at ru.vyarus.spock.jupiter.interceptor.ExtensionLifecycleMerger.interceptCleanupSpecMethod(ExtensionLifecycleMerger.java:180)
		at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:39)
		... 6 more

[xvik]

There is a problem in spock-junit5 because, essentially, it is an implementation of jupiter apis (simulation of jupiter api inside spock) and it was written for junit 5.10. It seems api have changed since then.
I have reproduced the problem with your repo, thank you.

I know about non-static fileds registration change in 5.11 and currently working on update. Will check more recent versions compatibility (and this issue) after that. But, the fix will take some time, sorry (not much spare time currently).

In general, spock-spring is a re-implementation of spring junit5 extension. There was no problem when spring used it's own annotations: spock runs spring (test) core and spring could activate its additional extensions.
Now @EnableWireMock is a pure junit5 extension, which is not directly emulated by spock (and not planned to be).
The only way to "fix" spock for this case is re-implementing wiremock junit5 extension (same way as spring extension). For sure it's possible, but there might be other pure junit 5 extensions that will not work.

That's why complete junit5 extensions support (spock-junit5) covers more potential cases: with api emulation, original spring test extension is used (not re-implementation) making the test work the same for both jupiter and spock (imagine if extension initialization logic would change, it would require the same change in spock implementation). Plus, (almost) any other junit5 extension could be used (no need to always write spock-specific versions).

disclaimer: I'm a spock-junit5 developer, not affiliated with spock team, so could only guess what could (would) be done in spock-spring.

[dlehammer]

Hi @xvik ,

Thank you for your elaboration 🙏

I've taken a look at the dependencies on the chore/spring-boot-4-upgrade+xvik_spock-junit5 branch, and I think that most of the symptoms most-likely are related to the new junit-jupiter v6 changes.
This is also the likely cause for spock-junit5 not being a drop-in replacement in a Spring Boot 4 context, as suggested earlier.

The excerpt below outlines how spring-boot-starter-test depends on junit-jupiter v6

+--- org.springframework.boot:spring-boot-starter-test -> 4.0.1
SNIP..
|    +--- org.junit.jupiter:junit-jupiter:6.0.1
|    |    +--- org.junit:junit-bom:6.0.1 (*)
|    |    +--- org.junit.jupiter:junit-jupiter-api:6.0.1
|    |    |    +--- org.junit:junit-bom:6.0.1 (*)
|    |    |    +--- org.opentest4j:opentest4j:1.3.0
|    |    |    +--- org.junit.platform:junit-platform-commons:6.0.1 (*)
|    |    |    +--- org.apiguardian:apiguardian-api:1.1.2
|    |    |    \--- org.jspecify:jspecify:1.0.0
|    |    \--- org.junit.jupiter:junit-jupiter-params:6.0.1
|    |         +--- org.junit:junit-bom:6.0.1 (*)
|    |         +--- org.junit.jupiter:junit-jupiter-api:6.0.1 (*)
|    |         +--- org.apiguardian:apiguardian-api:1.1.2
|    |         \--- org.jspecify:jspecify:1.0.0
SNIP..

The excerpt below outlines how the spock-spring dependency junit-jupiter v5.14.1 is overridden.

+--- org.spockframework:spock-spring -> 2.4-groovy-5.0
SNIP..
|         +--- org.junit:junit-bom:5.14.1 -> 6.0.1
|         |    +--- org.junit.jupiter:junit-jupiter:6.0.1 (c)
|         |    +--- org.junit.jupiter:junit-jupiter-api:6.0.1 (c)
|         |    +--- org.junit.jupiter:junit-jupiter-params:6.0.1 (c)
|         |    +--- org.junit.platform:junit-platform-commons:6.0.1 (c)
|         |    \--- org.junit.platform:junit-platform-engine:6.0.1 (c)
|         +--- org.junit.platform:junit-platform-engine -> 6.0.1
|         |    +--- org.junit:junit-bom:6.0.1 (*)
|         |    +--- org.opentest4j:opentest4j:1.3.0
|         |    +--- org.junit.platform:junit-platform-commons:6.0.1
|         |    |    +--- org.junit:junit-bom:6.0.1 (*)
|         |    |    +--- org.apiguardian:apiguardian-api:1.1.2
|         |    |    \--- org.jspecify:jspecify:1.0.0
|         |    +--- org.apiguardian:apiguardian-api:1.1.2
|         |    \--- org.jspecify:jspecify:1.0.0
SNIP..

The excerpt below outlines how the spock-junit5 dependency junit-jupiter v5.9.1 is overridden.

\--- ru.vyarus:spock-junit5:1.2.0
     \--- org.junit.jupiter:junit-jupiter-api:5.9.1 -> 6.0.1 (*)

Perhaps there's need for a spock-spring4 or spock-junit6 to support Spring Boot 4 🤔

[xvik]

spock-junit6 module released (thank you for the module name change idea).
I checked that your repo is working with it.
Please note that I did not reset version for the new artifact (to avoid silly mistakes when artifact name is not changed):

testImplementation 'ru.vyarus:spock-junit6:2.0.0'

I was hoping that dependabot would not create pull requests for version 2.0.0 as artifact name changed, but it still creates pull requests for it :( (it seems that it tracks versions by the repository). Also, there are incorrect links to github repo in pom but it will not cause problems.

Also (just to mention), spock-junit5 was also updated: 1.3.0 released for junit 5.11 (non-static fields initialization changed, add LifecycleMethodExecutionExceptionHandler support), 1.4.0 released for junit 5.12-5.14 (ExtensionContext API changes, added AutoClosable values support)

[dlehammer]

Hi @xvik ,

Thanks a bunch for pursuing this issue 💪

I've created a chore/spring-boot-4-upgrade+xvik_spock-junit6 branch, demonstrating the ru.vyarus:spock-junit6 support.

I can confirm ru.vyarus:spock-junit6 restores Spock parity across the reproducer test-suite.
+ allows for removal of the undesired Spring Boot 4 workaround, restoring parity with Spring Boot 3.

In conclusion; in-order for spock-spring to support Spring Boot 4, JUnit 6 support is required, I hope Spock 3.0 includes this progression.
(JUnit 6 is also slated for Gradle 10 default)

🤓