Spring ApplicationContext Caching

Spring’s test framework reuses compatible ApplicationContext instances across test classes to avoid repeatedly starting the application. This can substantially reduce test-suite startup time, while context changes or explicit configuration can cause a new context to be created.

In Spring testing, creating an ApplicationContext can be expensive because Spring must discover configuration, create beans, apply post-processors, and initialize infrastructure. The test framework therefore maintains a cache of contexts and can reuse a previously created context when another test requests an equivalent configuration.

Context reuse is based on the configuration that defines the test context, including factors such as configuration classes, active profiles, property sources, context customizers, and other test-specific settings. Two tests that request compatible contexts can share the same cached instance rather than starting Spring independently.

Annotations such as `@SpringBootTest`, `@ActiveProfiles`, `@TestPropertySource`, and `@MockBean` can affect the context configuration. If a test needs a materially different context, Spring creates another cache entry instead of reusing the incompatible one.

Tests can also mark a context dirty with `@DirtiesContext`. This tells the test framework that the cached context should no longer be reused for the affected scope, which trades test isolation for additional startup cost. In practice, excessive context variation and unnecessary `@DirtiesContext` usage are common causes of slow Spring test suites.

Key points

• Compatible test configurations can reuse the same cached `ApplicationContext`.
• Changing test configuration can produce a separate context and therefore another startup.
• `@DirtiesContext` invalidates cached context state for its configured scope.
• `@MockBean`, profiles, properties, and configuration choices can affect context compatibility.
• Reducing unnecessary context variation is important for fast Spring test suites.

Interview questions

Why does Spring cache ApplicationContexts during tests?

Starting a Spring ApplicationContext can be relatively expensive because many beans and framework components must be initialized. Reusing a compatible context avoids repeating that work for every test class. This can make a large integration-test suite substantially faster.

What kinds of changes can cause Spring to create a different cached context?

Spring builds the test context from configuration metadata, so changes to that metadata can affect cache reuse. Active profiles, test properties, configuration classes, context customizers, and mocked beans are examples of inputs that can distinguish contexts. If the resulting configuration is not compatible with an existing cache entry, Spring creates another context.

What does `@DirtiesContext` do?

`@DirtiesContext` tells Spring's test infrastructure that a context has been changed in a way that makes continued reuse inappropriate for the configured scope. The affected cached context is removed or marked for rebuilding according to the annotation's mode and scope. The next test that needs that context may therefore pay the startup cost again.

A Spring test suite is slow because it starts many contexts. How would you investigate it?

I would first identify how many distinct contexts are being created and look for configuration differences between tests. Then I would inspect profiles, properties, mock declarations, configuration classes, and context customizers that prevent reuse. I would also look for unnecessary `@DirtiesContext` usage. The goal is to group compatible tests around stable configurations while keeping tests isolated where isolation is actually required.