Spring Boot Integration Tests Are Slow and Messy: Here's How to Fix Them

Integration test suites can get slow without anyone deciding they should. Another @SpringBootTest here, some in-memory H2 wiring there, a flaky test "fixed" with a stray @DirtiesContext – and eventually the suite is the thing everyone quietly dreads before merging a PR, flaky on every other CI run, with nobody able to point to the one change that caused it.

Spring Boot integration tests do real work, validating behavior across controllers, services, repositories, databases, and messaging systems. That breadth is what makes them valuable, and it's also what makes them expensive. When you wire together a real application context, connect to databases, and exercise multiple layers in a single test run, costs add up fast. The question is whether those costs are unavoidable or whether your test suite pays for things it doesn't need.

This article walks through the specific mechanisms that make Spring Boot integration suites slow and brittle, and the practical strategies that address them. You'll also see how Kotlin's extension functions, DSLs, data classes, named arguments, and scope functions reduce the boilerplate that accumulates in integration test code over time, making the resulting suite easier to maintain regardless of the language you're already using.

Why Spring Boot integration tests slow down over time

Most suites start with a single @SpringBootTest class and a handful of tests. That first test class is harmless. The problems compound when a second developer adds another @SpringBootTest with a slightly different configuration, a third adds @ActiveProfiles("integration") to one class and @ActiveProfiles("test") to another, and a fourth drops a @DirtiesContext on a test that was flaky. Six months later, the suite boots five or six separate application contexts across a single run, and nobody realizes it.

Before you optimize anything, profile the actual bottleneck. Spring Boot's context initialization is usually the dominant cost, but database container startup and heavyweight test setup can be significant too. Run your tests with -Dspring.test.context.cache.maxSize=10 alongside JUnit's --report-dir output to see how many contexts are being created. If you see more than two or three distinct contexts in a moderate-sized suite, context proliferation is your problem.

Nearly every fix in this article reduces to a single idea: repeated initialization is the thing you're paying for, not the tests themselves. Whether that initialization is a Spring application context, a database container, or heavyweight test data, the fastest fix is almost always to do it once and reuse it rather than make each instance cheaper.

Keep the number of Spring application contexts small

@SpringBootTest loads your full application context, all beans, all configuration, all auto-configuration. For a non-trivial Spring Boot application, that initialization can take several seconds. The Spring TestContext Framework caches loaded contexts and reuses them across compatible tests, so the first test in a group pays the startup cost and subsequent tests don't.

The cache key is a composite of everything that affects the context, including configuration classes, active profiles, property sources, and context customizers. Change any of these between two test classes and Spring boots a second context. Common cache-busting patterns include using different @ActiveProfiles values across test classes, importing different @TestConfiguration classes with incompatible beans, and overusing @DirtiesContext.

@DirtiesContext signals that a test has modified the application context and that Spring should discard it. Using it broadly because a single test is flaky trades a flakiness problem for a performance problem. The test that genuinely modifies shared mutable state may warrant it, but the test that just needs a clean database table doesn't.

The practical target is a single shared context for your full integration tests, achieved by keeping configuration consistent. A shared base class or a single shared @TestConfiguration import applied consistently across test classes is the most reliable way to ensure the cache key matches. In Kotlin, the recommended approach combines constructor injection with @TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL), which avoids lateinit vars and keeps test fields immutable:

@SpringBootTest
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class OrderServiceIntegrationTest(
    private val orderService: OrderService,
    private val orderRepository: OrderRepository
) {

    @Test
    fun `placing an order persists it to the database`() {
        val order = orderService.place(OrderRequest(productId = "p-42", quantity = 3))
        val saved = orderRepository.findById(order.id)
        assert(saved.isPresent)
    }
}

The Kotlin plugin.spring compiler plugin automatically opens Spring-annotated classes, resolving the friction Kotlin's default final classes would otherwise cause with Spring's proxying, so no additional configuration is needed for this to work correctly.

None of this means avoiding @SpringBootTest. A full application context is the right tool whenever a test genuinely needs to exercise behavior that spans multiple layers, for example, an HTTP request that flows through a controller, a service, and a repository. The goal isn't eliminating full-context tests; it's making sure you're not accidentally paying the full-context startup cost two, three, or five times over in a single suite when one shared context would do.

Test slices selectively, not as a default performance fix

Spring Boot's test slices (@WebMvcTest, @DataJpaTest, @JdbcTest, @JsonTest, @RestClientTest) load only the portion of your application relevant to a specific concern. A @DataJpaTest context contains JPA repositories and the JPA layer, nothing else. A @WebMvcTest context contains MVC infrastructure without starting a full servlet container.

Slices are useful when a test genuinely exercises only one layer. A repository test that validates a complex JPQL query doesn't need your HTTP layer. A controller test that validates request validation logic doesn't need your database. For those cases, a slice gives you a faster, more focused test.

The trap is treating slices as a general performance fix. Each distinct slice configuration that differs from another creates its own application context. A suite with ten @DataJpaTest classes using the same configuration shares one context. A suite with five different slice types, each loaded with different imports, creates five separate contexts, and the cumulative startup cost can exceed that of a single, well-shared full context.

Use a slice when it provides a meaningful testing boundary for the layer under test. For tests that validate behavior spanning multiple layers, prioritize reusing a small number of shared full contexts over reaching for a narrower slice.

Use Testcontainers without repeatedly starting containers

H2 is a convenient in-memory database for local testing, but it doesn't behave like PostgreSQL or MySQL in ways that affect production correctness. PostgreSQL enforces stricter type checking, so implicit casts that H2 accepts silently will fail at runtime against Postgres. Indexing semantics differ, and constraint enforcement, particularly around deferred constraints and transaction isolation, behaves differently. A green test suite against H2 can mask bugs that surface only under the production database engine.

Testcontainers solves this by running your actual database engine in a Docker container during tests. The startup cost is real (a PostgreSQL container cold-start typically takes a few seconds), but you pay it once per suite, not once per test class.

With Spring Boot 3.1+, the @ServiceConnection annotation eliminates the boilerplate of manually wiring container ports into Spring's datasource configuration, and it's unchanged under Spring Boot 4. Declare the container in a shared @TestConfiguration class and import it wherever needed:

@TestConfiguration(proxyBeanMethods = false)
class TestcontainersConfiguration {

    @Bean
    @ServiceConnection
    fun postgresContainer(): PostgreSQLContainer<*> =
        PostgreSQLContainer("postgres:17-alpine")
}

For @DataJpaTest slices, Spring attempts to replace your datasource with an embedded database by default. Suppress that behavior with @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) and import your shared container configuration:

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
@Import(TestcontainersConfiguration::class)
class BookmarkRepositoryTest @Autowired constructor(
    private val bookmarkRepository: BookmarkRepository
) {

    @Test
    fun `should find bookmark by id`() {
        val bookmark = bookmarkRepository.save(
            Bookmark(title = "Kotlin Docs", url = "https://kotlinlang.org")
        )
        val found = bookmarkRepository.findById(bookmark.id!!)
        assertThat(found).isPresent
        assertThat(found.get().title).isEqualTo("Kotlin Docs")
    }
}

Two dependency details are worth getting right here if you're on Spring Boot 4. First, @DataJpaTest itself now lives in spring-boot-data-jpa-test, pulled in via the spring-boot-starter-data-jpa-test starter, not the plain spring-boot-starter-test. Second, @AutoConfigureTestDatabase moved too: it's now org.springframework.boot.jdbc.test.autoconfigure.AutoConfigureTestDatabase, shipped in a separate spring-boot-starter-jdbc-test starter that spring-boot-starter-data-jpa-test doesn't pull in automatically, so you need to add it explicitly:

testImplementation("org.springframework.boot:spring-boot-starter-data-jpa-test")
testImplementation("org.springframework.boot:spring-boot-starter-jdbc-test")
testImplementation("org.springframework.boot:spring-boot-testcontainers")
testImplementation("org.testcontainers:junit-jupiter")
testImplementation("org.testcontainers:postgresql")

@ServiceConnection itself, by contrast, didn't move; it's still org.springframework.boot.testcontainers.service.connection.ServiceConnection on Spring Boot 4. Not everything in the test-support space was reshuffled, just the test-slice annotations and the autoconfiguration classes that back them.

If you prefer declaring the container directly in the test class, Kotlin's companion objects with @JvmStatic ensure the container lifecycle spans all methods in the class rather than restarting for each test:

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
@Testcontainers
class OrderRepositoryTest {

    companion object {
        @Container
        @ServiceConnection
        @JvmStatic
        val postgres = PostgreSQLContainer("postgres:17-alpine").apply {
            withDatabaseName("testdb")
        }
    }

    @Autowired
    private lateinit var orderRepository: OrderRepository

    @Test
    fun `should save and retrieve an order`() {
        // test body
    }
}

The goal is to combine a reused container with a reused Spring context. When your test configuration is consistent, Spring's cache keeps the same context alive across all test classes that share the same container configuration, and the database container itself stays running for the duration of the build.

For database state, build only what each test actually needs. A test that validates order retrieval doesn't need a populated product catalog. Lightweight, targeted setup with @BeforeEach and @AfterEach cleanup (or transaction rollback via @Transactional) keeps tests isolated without requiring full database resets between every run.

A practical strategy for a fast integration test suite

The context sharing model below keeps a suite fast by mapping each test type to its context and container lifecycle:

The diagram below is the editable Mermaid source — useful if you want to adjust colors or labels. A rendered image follows it.

flowchart TD
    A[Full Integration Tests<br/>@SpringBootTest + Testcontainers] --> B[Single shared<br/>Spring context]
    C[Slice Tests<br/>@DataJpaTest etc.] --> D[Shared slice<br/>context per type]
    E[Unit Tests] --> F[No Spring context]
    B --> G[Postgres container<br/>started once]
    D --> G

The strategy has seven parts:

1. Keep one @TestConfiguration class that declares your Testcontainers beans with @ServiceConnection and import it consistently across all tests that need it.
2. Align profiles. If some test classes use @ActiveProfiles("test") and others don't declare a profile at all, Spring treats them as different configurations and creates separate contexts.
3. Reserve @DirtiesContext for tests that genuinely modify application-level state, not for tests with database state issues. Database state cleanup belongs in @AfterEach or via transactional rollback.
4. Reach for a test slice only when the test's meaningful scope is genuinely limited to that layer. A repository test for a complex query is a good slice candidate. A test that exercises an HTTP endpoint through to the database is not.
5. Start containers once and reuse them. Use withReuse(true) on your container definition to persist containers across JVM runs during local development, where it cuts iteration time substantially.
6. Build only the database state each test actually needs. Seeding a full product catalog for a test that only checks order retrieval adds setup cost without adding coverage.
7. Measure before and after changes. Run the test suite twice and enable DEBUG-level logging on org.springframework.test.context.cache (or equivalent context cache reporting) to confirm that context creation counts dropped and wall-clock time improved.

Make integration tests readable with Kotlin

Kotlin reduces the boilerplate that accumulates around integration tests, meaning less noise when a test fails and less maintenance when fixtures change. The techniques below don't make a suite faster on their own; they make an already-fast suite easier to read and maintain, which is what keeps it fast six months from now instead of sliding back into the state this article opened with.

Data classes eliminate the Java builder pattern for test fixtures. A Bookmark data class with sensible defaults can be constructed with a single named argument for the one field a specific test cares about:

data class BookmarkFixture(
    val title: String = "Default Title",
    val url: String = "https://kotlinlang.org",
    val isActive: Boolean = true
)

Named arguments make test data construction self-documenting. BookmarkFixture(title = "Archived Post", isActive = false) is readable without a builder chain.

Extension functions let you add setup utilities or assertion helpers directly to Spring test classes without inheritance hierarchies. A setup helper for building a JSON POST request:

fun MockMvc.postJson(url: String, payload: Any, objectMapper: ObjectMapper): ResultActionsDsl =
    post(url) {
        contentType = MediaType.APPLICATION_JSON
        content = objectMapper.writeValueAsString(payload)
        accept = MediaType.APPLICATION_JSON
    }

If you're on Spring Boot 4, the ObjectMapper import above is worth double-checking. Spring Boot 4 defaults to Jackson 3, pulled in through a new spring-boot-starter-jackson module, and Jackson 3's base package moved from com.fasterxml.jackson to tools.jackson, so the type you inject here is tools.jackson.databind.ObjectMapper, not the Jackson 2 class of the same simple name. If you're posting a Kotlin data class as the request body, also add tools.jackson.module:jackson-module-kotlin (the Jackson 3 equivalent of the familiar jackson-module-kotlin) as a dependency. Without it, Jackson can't resolve the data class's primary-constructor parameters, and the request fails with a 400 instead of a compile error, making it easy to lose an afternoon to.

And an assertion helper, scoped to the type it asserts on rather than to a test class:

fun Bookmark.assertIsActiveWithTitle(expectedTitle: String) {
    assertTrue(isActive)
    assertEquals(expectedTitle, title)
}

Kotlin DSLs built on extension functions and lambdas-with-receivers are what make the postJson helper above readable in the first place: post(url) { contentType = ...; content = ... } reads as configuration, not as a chain of setter calls. Spring's own MockMvc Kotlin DSL (post, get, .andExpect { status { isCreated() } }) follows the same pattern, and it's worth reaching for directly rather than only through a wrapping extension function when a test doesn't need one.

Scope functions (apply, also, run) clean up construction and setup code at the declaration site without extracting helper methods. apply is the one you'll reach for most, configuring an object and returning it, as in the companion-object container declaration from the Testcontainers section:

@JvmStatic
val postgres = PostgreSQLContainer("postgres:17-alpine").apply {
    withDatabaseName("testdb")
    withUsername("test")
    withPassword("test")
}

also is useful when you want to do something with a value, like logging it, without changing what gets returned, and run is useful for computing a value inline from a short block instead of a separate val statement:

val fixture = BookmarkFixture(title = "Kotlin Docs").also {
    println("creating bookmark fixture: ${it.title}")
}
val request = run {
    BookmarkRequest(title = fixture.title, url = fixture.url, isActive = fixture.isActive)
}

Put together, a small integration test combining a fixture, the postJson extension function, and a scope function reads as a short, flat sequence of steps rather than a wall of setup:

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
@AutoConfigureMockMvc
@Import(TestcontainersConfiguration::class)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class BookmarkControllerIntegrationTest(
    private val mockMvc: MockMvc,
    private val objectMapper: ObjectMapper
) {

    @Test
    fun `creating a bookmark returns it in the response`() {
        val fixture = BookmarkFixture(title = "Kotlin Docs").also {
            println("creating bookmark fixture: ${it.title}")
        }
        val request = run { BookmarkRequest(title = fixture.title, url = fixture.url, isActive = fixture.isActive) }

        mockMvc.postJson("/api/bookmarks", request, objectMapper)
            .andExpect { status { isCreated() } }
    }
}

Note that @AutoConfigureMockMvc moved packages in Spring Boot 4 too, same as @WebMvcTest: it's org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc now, shipped in spring-boot-webmvc-test via the spring-boot-starter-webmvc-test starter.

These are incremental improvements, not architectural changes. You can introduce Kotlin test code into an existing Java Spring project without touching production code, which makes it a low-risk starting point for teams evaluating what Kotlin brings to their codebase.

Organize integration tests for long-term maintainability

A suite that's fast today becomes slow again if there's no shared understanding of its structure. Keep three distinct categories separate: unit tests (no Spring context, run fast), slice tests (partial context, targeted), and full integration tests (full context, shared container). Mixing these in the same test source set makes it difficult to see at a glance why a build is slow. Consistent naming helps here too; a suffix convention like *Test for units and slices versus *IntegrationTest for full-context tests, or separate source directories, lets you tell at a glance (and in CI timing reports) which category is growing.

Integration tests should assert on business behavior, not implementation details. A test that verifies the correct HTTP status code and response body when a user places an order is durable. A test that verifies the exact SQL statement executed against the database is brittle and couples the test to an implementation that can change without breaking the business requirement.

Avoid duplicating setup logic across test classes just because it's easier than sharing it. A second @TestConfiguration import that's nearly identical to an existing one is exactly the kind of inconsistency that busts the context cache described earlier, so the maintainability concern and the performance concern point to the same fix.

Shared base classes are worth using when they genuinely simplify the suite, typically for consistent annotation setup and shared infrastructure, and worth avoiding when they become a dumping ground for setup logic that only some tests need. A shared annotations file (using Kotlin's @Target(AnnotationTarget.CLASS) composed annotations) is often cleaner:

@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.RUNTIME)
@SpringBootTest
@Import(TestcontainersConfiguration::class)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
annotation class IntegrationTest

Any @SpringBootTest class that uses @IntegrationTest instead gets a consistent cache key by definition, because the annotation composition is identical.

Treat test suite performance as an ongoing metric. Add context creation count and total suite duration to your CI output so regressions are visible before they compound. A suite that takes four minutes today will take twenty-two again in six months if nobody is watching the cost.

The fixes that move the needle on Spring Boot integration test performance share a common thread: reducing repeated initialization. Keep your Spring application contexts few and consistent so the cache does its job. Start Testcontainers infrastructure once and keep it alive across the test run. Use test slices when they define a genuine testing boundary, and avoid them when the goal is just a smaller context. Measure before and after so you know which bottleneck you actually solved.

Kotlin's language features sit naturally on top of this foundation. Data classes, extension functions, DSLs, named arguments, and scope functions cut boilerplate without changing how Spring tests work, making them a practical addition to a Java Spring project even before you change any production code. The formal partnership between JetBrains and Spring reflects this kind of incremental integration, with Kotlin as a natural evolution of the JVM development experience that complements your existing ecosystem. For a sense of what that looks like at scale, Verifone's architect discussed running Kotlin in mission-critical payment systems at KotlinConf, where reliability requirements are just as unforgiving as anything a slow test suite is standing in for.