Introduction

If you want a Spock test to exercise the real Spring Boot application, you should start the full application context instead of mocking the web layer by hand. In practice that means using @SpringBootTest, choosing an appropriate web environment, and writing the specification so Spring can inject the beans or HTTP client you need.

Basic Spock Integration Test Setup

A full integration test with an embedded server usually looks like this:

1import org.springframework.beans.factory.annotation.Autowired
2import org.springframework.boot.test.context.SpringBootTest
3import org.springframework.boot.test.web.client.TestRestTemplate
4import org.springframework.boot.test.web.server.LocalServerPort
5import spock.lang.Specification
6
7@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
8class GreetingIntegrationSpec extends Specification {
9
10    @LocalServerPort
11    int port
12
13    @Autowired
14    TestRestTemplate restTemplate
15
16    def "returns greeting from running application"() {
17        when:
18        def body = restTemplate.getForObject("http://localhost:${port}/greet", String)
19
20        then:
21        body == "hello"
22    }
23}

@SpringBootTest tells Spring Boot to start the application the same way it would for normal runtime. RANDOM_PORT is a safe default because it avoids collisions with other processes during test runs.

Dependencies You Usually Need

For Gradle, the essential testing dependencies are Spring Boot test support and Spock.

1dependencies {
2    testImplementation 'org.springframework.boot:spring-boot-starter-test'
3    testImplementation 'org.spockframework:spock-core:2.4-M4-groovy-4.0'
4    testImplementation 'org.spockframework:spock-spring:2.4-M4-groovy-4.0'
5}

The exact Spock version should match your Groovy version. That version alignment matters more than most test-setup guides admit.

Choosing the Right Test Style

Not every integration test needs a running HTTP server.

Use webEnvironment = NONE when you only want the application context and beans:

1@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE)
2class BillingServiceSpec extends Specification {
3
4    @Autowired
5    BillingService billingService
6
7    def "calculates total"() {
8        expect:
9        billingService.total(10, 3) == 13
10    }
11}

Use RANDOM_PORT when you want to test HTTP behavior end to end. Use MOCK when you want Spring MVC infrastructure without a real embedded container.

Isolating Test Configuration

Integration tests should usually run with a dedicated profile.

1import org.springframework.test.context.ActiveProfiles
2
3@ActiveProfiles("test")
4@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
5class GreetingIntegrationSpec extends Specification {
6}

Then create application-test.yml with a test database or fake external endpoints. That keeps the test bootstrapping realistic without pointing at production services.

Testing Database-Backed Behavior

If the application touches a database, make the test environment explicit. For small projects, an in-memory database is often enough. For production-like behavior, a containerized database is usually more honest.

A service-level integration spec can still use the same bootstrapping approach:

1@SpringBootTest
2@ActiveProfiles(\"test\")
3class UserRepositorySpec extends Specification {
4
5    @Autowired
6    UserRepository userRepository
7
8    def \"saves and loads a user\"() {
9        when:
10        def saved = userRepository.save(new User(name: \"Ada\"))
11
12        then:
13        userRepository.findById(saved.id).get().name == \"Ada\"
14    }
15}

The important part is not the assertion. It is that the full application wiring, transactions, and configuration are exercised together.

Keeping Startup Predictable

When integration tests boot the application, remove anything non-essential from the startup path. Scheduled jobs, message consumers, and calls to real third-party services make tests slower and less deterministic. A test profile can disable those pieces while still starting the same Spring Boot application shape that production uses.

That balance is the point of the test: real bootstrapping, controlled dependencies.

Common Pitfalls

The most common failure is missing spock-spring, which prevents Spring-specific annotations from behaving correctly.

Another common issue is using an incompatible Spock and Groovy combination. If the versions do not line up, the application may fail before any test runs.

A third pitfall is using a fixed port instead of RANDOM_PORT, which makes tests flaky on CI when the port is already in use.

Summary

• Use @SpringBootTest to start the real Spring Boot application in a Spock integration test.
• 'RANDOM_PORT is the safest option for full HTTP integration tests.'
• Add both spock-core and spock-spring, and keep them aligned with Groovy.
• Use webEnvironment = NONE when you only need the Spring context, not a server.
• Isolate integration test settings with a dedicated Spring profile.