
This is a comprehensive testing guide for Spring Boot 4 applications that cuts through the noise with a clear decision tree: use @WebMvcTest for controllers, @DataJpaTest for repositories, and plain JUnit for business logic. It emphasizes modern tools like MockMvcTester and RestTestClient over legacy alternatives, pairs everything with AssertJ for readable assertions, and includes practical references for each test slice. The best practices section is pragmatic, recommending 80% coverage with Jacoco and suggesting refactoring when a method needs more than 5-7 test cases. It's opinionated about the test pyramid and context caching, which is exactly what you want when learning a testing stack this deep.
$ npx -y skills add github/awesome-copilot --skill spring-boot-testing --agent claude-codeInstalls into .claude/skills of the current project.
This skill provides expert guidance for testing Spring Boot applications with modern patterns and best practices. Examples target Spring Boot 4; see the compatibility note below for Boot 3.
Read the project's Spring Boot version and test dependencies before writing tests, and do not upgrade them implicitly.
| Spring Boot 3.x | Spring Boot 4.x | |
|---|---|---|
| JUnit | 5 (Jupiter) | 6 by default (same org.junit.jupiter.api annotations; JUnit 5 tests keep working) |
| Mock beans | @MockitoBean / @MockitoSpyBean from 3.4 (Spring Framework 6.2); @MockBean / @SpyBean are deprecated | @MockitoBean replaces @MockBean (do not use the old ones) |
| Test starters | spring-boot-starter-test covers everything | modular: add spring-boot-starter-webmvc-test, spring-boot-starter-data-jpa-test, ... |
| Slice imports | org.springframework.boot.test.autoconfigure... | moved, e.g. org.springframework.boot.webmvc.test.autoconfigure.WebMvcTest |
| Testcontainers | 1.x names | 2.x names (testcontainers-postgresql) |
Details: references/sb4-migration.md, references/mockitobean.md.
| Scenario | Annotation | Reference |
|---|---|---|
| Controller + HTTP semantics | @WebMvcTest | references/webmvctest.md |
| Repository + JPA queries | @DataJpaTest | references/datajpatest.md |
| REST client + external APIs | @RestClientTest | references/restclienttest.md |
| JSON (de)serialization | @JsonTest | references/test-slices-overview.md |
| Full application | @SpringBootTest | references/test-slices-overview.md |
@ServiceConnection quickstart, PostgreSQL, MySQL, etc.*IT classes silently skipped unless Failsafe is bound; run ./mvnw verifyMaven gotcha: Failsafe declared only in
<pluginManagement>means*ITtests never run. Declare it in<build><plugins>with theintegration-testandverifygoals and run./mvnw verify.
Testing a controller endpoint?
Yes → @WebMvcTest with MockMvcTester
Testing repository queries?
Yes → @DataJpaTest with Testcontainers (real DB)
Testing business logic in service?
Yes → Plain JUnit + Mockito (no Spring context)
Testing external API client?
Yes → @RestClientTest with MockRestServiceServer
Testing JSON mapping?
Yes → @JsonTest
Need full integration test?
Yes → @SpringBootTest with minimal context config
When a method or class is too complex to test effectively:
Example of refactoring recommendation:
// Before: Complex method hard to test
public Order processOrder(OrderRequest request) {
// Validation, discount calculation, payment, inventory, notification...
// 50+ lines of mixed concerns
}
// After: Refactored into testable units
public Order processOrder(OrderRequest request) {
validateOrder(request);
var order = createOrder(request);
applyDiscount(order);
processPayment(order);
updateInventory(order);
sendNotification(order);
return order;
}
Create helper methods for commonly used objects and mock setup to enhance readability and maintainability.
Use descriptive display names to clarify test intent:
@Test
@DisplayName("Should calculate discount for VIP customer")
void shouldCalculateDiscountForVip() { }
@Test
@DisplayName("Should reject order when customer has insufficient credit")
void shouldRejectOrderForInsufficientCredit() { }
Always structure tests in this order:
Write tests with real production scenarios in mind. This makes tests more relatable and helps understand code behavior in actual production cases.
Aim for 80% code coverage as a practical balance between quality and effort. Higher coverage is beneficial but not the only goal.
Use Jacoco maven plugin for coverage reporting and tracking.
Coverage Rules:
What to Prioritize:
See also: https://docs.spring.io/spring-boot/reference/testing/spring-boot-applications.html and https://docs.spring.io/spring-boot/reference/features/dev-services.html.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<!-- For WebMvc tests -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webmvc-test</artifactId>
<scope>test</scope>
</dependency>
<!-- For Testcontainers -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-testcontainers</artifactId>
<scope>test</scope>
</dependency>
Sponsors