Use appropriate test slices like @WebMvcTest for controllers, @DataJpaTest for repositories, and avoid @SpringBootTest unless full context is needed. 2. Prefer unit tests with Mockito for service layers to keep tests fast and isolated. 3. Use @SpringBootTest with @AutoConfigureTestDatabase for integration tests, opting for in-memory databases like H2 or Testcontainers. 4. Leverage Testcontainers for realistic integration testing with real databases such as PostgreSQL. 5. Organize tests with proper structure, use application-test.yml for test-specific configuration, and mirror main package layout. 6. Measure test coverage with JaCoCo and enforce it in CI, while testing edge cases. 7. Avoid test smells by keeping integration tests focused, not relying on execution order, minimizing @DirtiesContext, and using @BeforeEach appropriately. Balancing unit, slice, and integration tests ensures reliable, maintainable, and fast Spring Boot applications.

Testing Java applications with Spring Boot can be efficient and reliable when you follow established best practices. Spring Boot provides excellent support for testing through its testing starter and integration with JUnit, Mockito, and Testcontainers. Here’s how to do it right.

1. Use the Right Test Slice for the Job

Spring Boot supports test slicing, which lets you load only the parts of the application context necessary for a specific test. This keeps tests fast and focused.

• @WebMvcTest – Use for testing web layers (controllers). It auto-configures MockMvc and disables full context loading.

  

  @WebMvcTest(UserController.class)
  class UserControllerTest {
      @Autowired
      private MockMvc mockMvc;
  }

• @DataJpaTest – For testing JPA repositories. Runs in a transaction that rolls back by default.

  @DataJpaTest
  class UserRepositoryTest {
      @Autowired
      private TestEntityManager entityManager;
      @Autowired
      private UserRepository userRepository;
  }

• @JsonTest – For testing JSON serialization/deserialization with @JsonComponent.

  

• @ServiceTest or plain unit tests – For service layers, often better tested without Spring context using mocks (e.g., Mockito).

Only use @SpringBootTest when you need the full context — it’s slower.

2. Prefer Unit Tests Over Integration Tests When Possible

Not every test needs Spring.

• Service or utility classes can (and should) be tested in isolation.

• Use Mockito to mock dependencies:

  @ExtendWith(MockitoExtension.class)
  class UserServiceTest {
      @Mock
      private UserRepository userRepository;
      @InjectMocks
      private UserService userService;
  
      @Test
      void shouldReturnUserWhenFound() {
          when(userRepository.findById(1L)).thenReturn(Optional.of(new User("John")));
          User result = userService.getUser(1L);
          assertEquals("John", result.getName());
      }
  }

This avoids spinning up the Spring context and runs faster.

3. Use @SpringBootTest Wisely for Integration Tests

When you need the full app context (e.g., testing end-to-end behavior), use @SpringBootTest.

• It loads the complete configuration by default.

• Combine with @AutoConfigureTestDatabase to replace production DB with an in-memory one:

  @SpringBootTest
  @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)
  class UserIntegrationTest {
      @Autowired
      private UserRepository userRepository;
  }

• Use webEnvironment = WebEnvironment.MOCK (default) for MockMvc, or RANDOM_PORT if you need a real server.

Avoid using real databases in CI; opt for H2 or Testcontainers instead.

4. Use Testcontainers for Realistic Integration Testing

For tests that require real infrastructure (PostgreSQL, Redis, Kafka), Testcontainers is a game-changer.

Example with PostgreSQL:

@SpringBootTest
@Testcontainers
class ContainerizedIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15")
        .withDatabaseName("testdb");

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Test
    void shouldSaveUserToRealDatabase() {
        // test with real JPA and DB
    }
}

This gives confidence your app works with actual databases, not just mocks.

5. Organize Test Structure and Use application-test.yml

• Set spring.profiles.active=test to load application-test.yml.

• Use this profile to configure test-specific settings:

  spring:
    datasource:
      url: jdbc:h2:mem:testdb
    jpa:
      hibernate:
        ddl-auto: create-drop
    sql:
      init:
        mode: never

• Keep test code in src/test/java mirroring main package structure.

• Name tests clearly: ServiceNameTest, ControllerNameIntegrationTest.

6. Don’t Forget Test Coverage and CI

• Use Jacoco to measure test coverage.
• Run tests in your CI pipeline on every push.
• Fail builds if coverage drops below a threshold.

Also, test edge cases: null inputs, exceptions, validation failures.

7. Clean Up and Avoid Test Smells

• Avoid overly large integration tests — they’re slow and brittle.
• Don’t rely on test execution order.
• Use @DirtiesContext sparingly — it slows things down.
• Prefer @BeforeEach over @BeforeAll unless truly necessary.

Basically, the key is balance: unit test logic in isolation, slice tests for components, and integration tests only when needed — ideally with realistic infrastructure via Testcontainers.

That’s how you keep your Spring Boot app reliable, maintainable, and fast to test.

The above is the detailed content of Best Practices for Testing Java Applications with Spring Boot. For more information, please follow other related articles on the PHP Chinese website!