Testing Spring Boot Applications

@SpringBootTest & the Test Context

18 min Lesson 3 of 13

@SpringBootTest & the Test Context

Unit tests with plain JUnit 5 and Mockito work well for isolated logic, but sooner or later you need to verify that your beans wire together correctly, that your configuration properties load, or that a real HTTP request reaches the right handler. That is where @SpringBootTest comes in: it bootstraps a full (or partial) Spring ApplicationContext inside your test, giving you the same IoC container your production application runs with.

What @SpringBootTest Actually Does

When you annotate a test class with @SpringBootTest, Spring Boot's test infrastructure does the following:

Locates your main @SpringBootApplication class by walking up the package tree from the test class.
Builds the full ApplicationContext — scanning components, processing @Configuration classes, running auto-configuration, and binding application.properties / application.yml.
Injects beans into the test class via @Autowired, just like any other Spring-managed bean.

By default, no server starts. @SpringBootTest creates the full context but does NOT listen on a port unless you set webEnvironment. For tests that only need to call service or repository beans directly, the default (no server) is faster and perfectly sufficient.

The simplest possible integration test looks like this:

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
class OrderServiceIntegrationTest {

    @Autowired
    private OrderService orderService;   // real bean from the container

    @Test
    void shouldCalculateTotalCorrectly() {
        Order order = orderService.findById(1L);
        assertThat(order.getTotal()).isPositive();
    }
}

The webEnvironment Attribute

@SpringBootTest accepts a webEnvironment parameter that controls whether and how an embedded server is started:

MOCK (default): Loads a WebApplicationContext with a mock Servlet environment. No real port. Use with MockMvc.
RANDOM_PORT: Starts the embedded server on a random free port. Ideal for full end-to-end HTTP tests using TestRestTemplate or WebTestClient. Port is injected with @LocalServerPort.
DEFINED_PORT: Starts on the port defined in application.properties (default 8080). Risky in CI — two tests running in parallel would clash.
NONE: Loads an ApplicationContext with no web environment at all. Useful for testing service-layer beans in a non-web app.

// Full HTTP round-trip test on a random port
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class OrderApiIntegrationTest {

    @LocalServerPort
    private int port;

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    void getOrderReturns200() {
        ResponseEntity<OrderDto> response =
            restTemplate.getForEntity("http://localhost:" + port + "/api/orders/1", OrderDto.class);

        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
    }
}

Context Caching — The Most Important Performance Feature

Bootstrapping a Spring context takes time: component scanning, auto-configuration, HikariCP pool creation, Hibernate schema validation — all of this can add 2–5 seconds per context. If every test class created its own context, a suite of 200 tests could easily spend more time in setup than in assertions.

Spring's test framework solves this with context caching: a context is started once per unique configuration key and reused by every test class that shares that key. The cache key is derived from:

The set of context configuration annotations (@SpringBootTest, @ContextConfiguration, etc.).
The webEnvironment value.
Any active profiles (@ActiveProfiles).
Any property overrides (properties attribute or @TestPropertySource).
Any @MockBean or @SpyBean declarations (each unique combination creates a separate context).

Design your test suite for context reuse. Group tests that share the same configuration into the same test class or into classes under a common base class. Keep @MockBean declarations to the minimum necessary — every new @MockBean combo forces a fresh context.

// Base class — context loaded once for all subclasses sharing this setup
@SpringBootTest
@ActiveProfiles("test")
abstract class AbstractIntegrationTest {
    // shared helpers, @Autowired common beans, @BeforeEach cleanup
}

// Reuses the context cached for @SpringBootTest + profile "test"
class OrderServiceTest extends AbstractIntegrationTest { ... }

// Also reuses the same cached context — no extra startup cost
class ProductServiceTest extends AbstractIntegrationTest { ... }

Using a Dedicated Test Application Properties File

Production databases and third-party API keys must not be used in tests. Place an src/test/resources/application.properties (or application-test.yml) file alongside your test sources. Spring Boot's test slice picks it up automatically and it takes precedence over the main one when running tests.

# src/test/resources/application.properties

# Use an in-memory H2 database — no Docker, no cleanup needed
spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1
spring.datasource.driver-class-name=org.h2.Driver
spring.jpa.hibernate.ddl-auto=create-drop

# Silence noisy SQL logs during tests
spring.jpa.show-sql=false
logging.level.org.hibernate=WARN

If only a handful of tests need special properties, use the inline properties attribute instead of a file — it keeps the override visible next to the annotation:

@SpringBootTest(properties = {
    "app.feature.payment-gateway=stub",
    "spring.jpa.hibernate.ddl-auto=create-drop"
})
class PaymentIntegrationTest { ... }

Avoid @DirtiesContext unless you truly need it. This annotation tells Spring to destroy and rebuild the context after the annotated test (class or method). It guarantees isolation but completely defeats context caching — and is one of the most common causes of slow test suites. Prefer database rollback (via @Transactional on the test method) or Testcontainers lifecycle management for isolation.

When to Use @SpringBootTest vs Sliced Tests

Spring Boot ships several focused test slices — @WebMvcTest, @DataJpaTest, @JsonTest, and others — that load only the portion of the context relevant to one layer. @SpringBootTest is the right choice when:

You need to test the integration of multiple layers (e.g. controller → service → repository).
You are testing auto-configuration behaviour — checking that your application.properties correctly initialises a complex bean.
You are writing smoke tests that confirm the application context loads without error (contextLoads()).

For tests that target a single layer in isolation, prefer the appropriate slice annotation — it starts faster and pins failures to the correct layer. A well-structured test suite uses both: sliced tests for the majority of coverage and a small number of @SpringBootTest integration tests to verify the wiring end-to-end.

Summary

@SpringBootTest bootstraps the complete ApplicationContext for your tests, with fine-grained control over the web environment through the webEnvironment attribute. Context caching means the expensive startup cost is paid once per unique configuration — so structuring your tests to share configuration is the single biggest lever for keeping your integration test suite fast. Use a dedicated application.properties in src/test/resources to swap production infrastructure (databases, queues, external APIs) for lightweight test doubles, and reach for @SpringBootTest when you need to verify cross-layer wiring rather than isolated component behaviour.