Spring Test Context Caching

Direct Answer

The Spring TestContext framework caches an ApplicationContext under a key built from its configuration, including locations, classes, initializers, profiles, properties, customizers, and parent context. Tests with the same key can reuse it in the same process, avoiding another startup. The cache has a size limit, can evict entries, and is not shared across forked JVM processes.

Code Example

// Test 1 — loads a context, cached under key: default config, no properties
@SpringBootTest
class OrderServiceTest {
    @Test void shouldCreateOrder() { /* uses the cached context */ }
}

// Test 2 — reuses the cached context because config is identical
@SpringBootTest
class CustomerServiceTest {
    @Test void shouldCreateCustomer() { /* reuses OrderServiceTest's context */ }
}

// Test 3 — NEW context, because the properties differ
@SpringBootTest(properties = "spring.datasource.url=jdbc:h2:mem:testdb2")
class InventoryServiceTest {
    @Test void shouldUpdateInventory() { /* separate context, cached separately */ }
}

// Test 4 — NEW context, because @DirtiesContext throws the old one away
@SpringBootTest
@DirtiesContext // forces a context reload after this class
class PaymentServiceTest {
    @Test void shouldProcessPayment() { /* context discarded after this class */ }
}

Common Mistakes & Pitfalls

• Using @DirtiesContext everywhere: It removes a reusable context from the cache, so later matching tests must create it again.
• Varying configuration accidentally: Different properties, profiles, dynamic-property values, imports, or context-customizing mocks can produce different keys.
• Treating a context reset as database cleanup: @DirtiesContext controls the application context. For database state, use a test-managed transaction when its boundary fits, or perform explicit cleanup.