The Hidden Spring Boot Feature For 10x Faster Builds 🔄
How Spring Reuses Test Contexts (when you let it) 🍃
Hi Mailwal,
Yesterday I showed you test slicing - how to go from 18 minutes to 4 minutes.
Today I'll show you how to go from 4 minutes to 90 seconds.
The technique: Spring context caching.
Yesterday I showed you test slicing - how to go from 18 minutes to 4 minutes.
Today I'll show you how to go from 4 minutes to 90 seconds.
The technique: Spring context caching.
What Spring Boot does behind the scenes
Here's something most developers don't realize:
Spring Boot tries to reuse test contexts across your test suite.
When you run your tests, Spring doesn't create a brand new ApplicationContext for every single test class. It creates one, runs all the tests that use that configuration, then reuses it for the next compatible test class.
This is massive for performance.
Creating a Spring context takes 5-15 seconds depending on your application size.
If Spring can reuse that context across 20 test classes instead of creating it 20 times, you save 100-300 seconds.
Spring Boot tries to reuse test contexts across your test suite.
When you run your tests, Spring doesn't create a brand new ApplicationContext for every single test class. It creates one, runs all the tests that use that configuration, then reuses it for the next compatible test class.
This is massive for performance.
Creating a Spring context takes 5-15 seconds depending on your application size.
If Spring can reuse that context across 20 test classes instead of creating it 20 times, you save 100-300 seconds.
The problem: Breaking the cache
But here's where teams shoot themselves in the foot.
Spring can only reuse a context if the configuration is identical.
If two test classes need even slightly different Spring configurations, Spring has to create a new context.
And there are dozens of ways to accidentally break context caching.
Spring can only reuse a context if the configuration is identical.
If two test classes need even slightly different Spring configurations, Spring has to create a new context.
And there are dozens of ways to accidentally break context caching.
Example 1: Different @MockBean declarations
Let's say you have three controller test classes.
- OrderControllerIT uses @MockBean for UserService
- PaymentControllerIT uses @MockBean for PaymentService
- NotificationControllerIT uses @MockBean for EmailService
Each test class mocks a different service. To you, these look similar - just controller tests with one mock each.
But to Spring, these are three completely different contexts.
Why?
Because the set of mocked beans is different in each case. Spring sees:
But to Spring, these are three completely different contexts.
Why?
Because the set of mocked beans is different in each case. Spring sees:
- Context A: @SpringBootTest + UserService mocked
- Context B: @SpringBootTest + PaymentService mocked
- Context C: @SpringBootTest + EmailService mocked
Three contexts = three context creations = 36 seconds wasted.
If you had instead used a shared test configuration where all three services are mocked together, Spring would create one context and reuse it for all three test classes.
One context = 12 seconds total.
36 seconds down to 12 seconds just by standardizing your mocks.
If you had instead used a shared test configuration where all three services are mocked together, Spring would create one context and reuse it for all three test classes.
One context = 12 seconds total.
36 seconds down to 12 seconds just by standardizing your mocks.
Example 2: Different @ActiveProfiles
This one catches teams all the time.
You have integration tests that need different profile configurations:
You have integration tests that need different profile configurations:
- DatabaseIT uses @ActiveProfiles("test")
- SecurityIT uses @ActiveProfiles("test-security")
- MessageQueueIT uses @ActiveProfiles("test-mq")
Each test class activates a different profile. Makes sense, right? Different tests need different configurations.
But again, to Spring these are three different contexts.
Spring sees:
But again, to Spring these are three different contexts.
Spring sees:
- Context A: @SpringBootTest + "test" profile
- Context B: @SpringBootTest + "test-security" profile
- Context C: @SpringBootTest + "test-mq" profile
Three unique configurations = three contexts = another 36 seconds.
The fix? Create one unified "test" profile that includes everything you need for testing, or carefully structure your profiles so multiple test classes can share the same profile configuration.
The fix? Create one unified "test" profile that includes everything you need for testing, or carefully structure your profiles so multiple test classes can share the same profile configuration.
The @DirtiesContext final boss
This is the most expensive annotation in Spring Boot testing.
@DirtiesContext tells Spring: "This test modified the context, throw it away and create a new one."
I see it used in two devastating ways:
Way 1: At the class level
After this entire test class runs, destroy the context. If you have 20 test classes with @DirtiesContext, that's 20 context creations even if they all could have shared the same configuration.
Way 2: At the method level
After EVERY test method in this class, destroy the context and create a new one. If the class has 10 test methods, that's 10 context creations for one test class. 10 × 12 seconds = 2 minutes for a single file.
@DirtiesContext tells Spring: "This test modified the context, throw it away and create a new one."
I see it used in two devastating ways:
Way 1: At the class level
After this entire test class runs, destroy the context. If you have 20 test classes with @DirtiesContext, that's 20 context creations even if they all could have shared the same configuration.
Way 2: At the method level
After EVERY test method in this class, destroy the context and create a new one. If the class has 10 test methods, that's 10 context creations for one test class. 10 × 12 seconds = 2 minutes for a single file.
How to spot context caching problems
Configure logging for Spring TestContext caching, run your test suite and look at the console output. Spring logs when it creates contexts:
"Spring test ApplicationContext cache statistics: hitCount=89, missCount=234"
This means:
"Spring test ApplicationContext cache statistics: hitCount=89, missCount=234"
This means:
- 89 times Spring reused an existing context (good!)
- 234 times Spring had to create a new context (expensive!)
That's a 27% cache hit rate. Terrible.
A healthy Spring Boot test suite should have an 80-90% cache hit rate.
If yours is below 50%, you're creating way too many contexts. Time to hunt down the culprits.
A healthy Spring Boot test suite should have an 80-90% cache hit rate.
If yours is below 50%, you're creating way too many contexts. Time to hunt down the culprits.
Action step
Do this right now:
- Search your codebase for @MockBean. How many unique combinations do you have?
- Search for @ActiveProfiles. How many different profile configurations?
- Search for @DirtiesContext. Do you actually need it, or can you use proper cleanup instead?
Each unique combination is a separate context.
Each @DirtiesContext is throwing away reusable work.
Tomorrow, I'll share a real customer story: how I helped a SaaS team go from 25 minutes to 12 minutes by eliminating @DirtiesContext misuse across 43 test classes.
PS: Module 8 of the Testing Masterclass covers Spring context caching in detail. I walk you through auditing your cache hit rate, identifying every context cache breaker in your codebase, and restructuring tests to maximize reuse. You'll see exactly which annotations break caching and how to fix each one.
Joyful testing,
Philip
Each @DirtiesContext is throwing away reusable work.
Tomorrow, I'll share a real customer story: how I helped a SaaS team go from 25 minutes to 12 minutes by eliminating @DirtiesContext misuse across 43 test classes.
PS: Module 8 of the Testing Masterclass covers Spring context caching in detail. I walk you through auditing your cache hit rate, identifying every context cache breaker in your codebase, and restructuring tests to maximize reuse. You'll see exactly which annotations break caching and how to fix each one.
Joyful testing,
Philip
Copyright © 2026 PragmaTech Digital Solutions Philip Riecks, All rights reserved.
You are receiving this email because you opted in at our website https://rieckpil.de
Our mailing address is:
You are receiving this email because you opted in at our website https://rieckpil.de
Our mailing address is:
PragmaTech Digital Solutions Philip Riecks
Paul-Gossen-Straße 75
c/o Design Offices
Erlangen91052
Germany
