Spring Boot test sliceshard5-8 years

A CI job's Spring test phase went from 3 to 14 minutes over six months, while the number of tests grew by only 20%. CPU is high, the database is idle, and there are 60 `@SpringBootTest` and `@WebMvcTest` classes. What do you suspect, how do you measure it, and what changes would you make?

The Spring TestContext framework caches application contexts across test classes, keyed by the full configuration a class asks for: the annotations, the @MockitoBean/@MockBean set, @Imports, active profiles and properties. Two classes with an identical key share one context; any difference means a new context started from scratch. A suite where every class has its own mix of mocked beans or a @TestPropertySource is starting dozens of contexts, which is CPU-bound work and matches the symptoms. Measure first with the cache's own statistics logger, then converge the keys: one composed annotation per kind of test, the same @MockitoBean set everywhere, properties in application-test.yml, and @DirtiesContext removed wherever a reset would do.

The lesson behind it →
More on Spring Boot test slices