What is the difference between @SpringBootTest and the "slice" test annotations like @WebMvcTest and @DataJpaTest?

@SpringBootTest boots the entire ApplicationContext (or a meaningfully large slice of it), giving the most realistic end-to-end test but at a real cost in startup time and broader scope than most individual tests actually need. The 'slice' annotations (@WebMvcTest, @DataJpaTest, @JsonTest, etc.) load only the specific subset of auto-configuration relevant to one architectural layer, auto-configuring just what's needed (e.g., @WebMvcTest wires up Spring MVC infrastructure and MockMvc, but not the full persistence layer) — much faster and more focused, at the cost of not exercising the full stack together.

How do you test a REST controller with MockMvc?

MockMvc simulates HTTP requests against Spring MVC's dispatch mechanism without starting a real HTTP server or opening a real network socket, letting you assert on the resulting status code, headers, and response body using a fluent API. It's typically auto-configured by @WebMvcTest (with collaborating service beans replaced by mocks) or obtained via MockMvcBuilders/@AutoConfigureMockMvc when using a fuller @SpringBootTest context, and is significantly faster than spinning up a real embedded server and issuing actual HTTP calls with a client like RestTemplate/WebTestClient.

What is the difference between @MockBean (or @MockitoBean) and Mockito's plain mock()?

Mockito's plain mock(SomeType.class) creates a mock object entirely outside of Spring — useful in a pure unit test that constructs the class under test directly with new, with no Spring context involved at all. @MockitoBean (the modern replacement for the deprecated @MockBean) creates a Mockito mock and additionally registers it as a bean inside the Spring test ApplicationContext, replacing whatever real bean of that type would otherwise have been wired in — necessary whenever the class under test is itself resolved and injected by Spring (e.g., inside a @WebMvcTest or @SpringBootTest) rather than constructed directly by the test.

How do Testcontainers help with integration testing in Spring Boot?

Testcontainers spins up real, throwaway instances of external dependencies (a real PostgreSQL, Kafka, Redis, etc.) inside Docker containers, scoped to a test run, instead of relying on an in-memory substitute (like H2 standing in for a real production database) or a shared, hand-maintained test environment. This gives much higher confidence that integration tests reflect real production behavior — including database-specific SQL features, constraints, and quirks an in-memory substitute wouldn't accurately reproduce — while remaining fully automated and disposable, with no persistent external test infrastructure to maintain.

How do Spring's test-specific transaction semantics (@Transactional on tests) affect test isolation?

Placing @Transactional on a Spring test method (or class) wraps that test in a transaction that, by default, is automatically rolled back at the end of the test — regardless of whether the test's code commits or not — so any database changes made during the test never persist beyond it, keeping each test isolated from the next without needing manual cleanup code. This is convenient specifically for tests against a real (or Testcontainers-backed) database, but doesn't replace verifying actual commit behavior when a test genuinely needs to check what happens across separate transactions.

How do you use test-specific configuration (@TestPropertySource, application-test.yml, test profiles)?

Test-specific configuration lets you override properties (a test database URL, a disabled external integration, a faster-but-less-secure encoder) only for the test run, without touching the application's real configuration files. Common approaches: an application-test.yml/properties file activated via a dedicated 'test' Spring profile (@ActiveProfiles("test")), or @TestPropertySource to set/override specific properties directly on a test class, both of which layer on top of (and can override) the application's normal configuration precedence.

What's the right balance between unit tests, slice tests, and full integration tests in a Spring Boot application?

A healthy Spring Boot test suite generally follows a pyramid shape: many fast, isolated unit tests (plain JUnit + Mockito, no Spring context, testing business logic directly) at the base; a moderate number of slice tests (@WebMvcTest, @DataJpaTest) verifying each layer's Spring-specific wiring and behavior in the middle; and a smaller number of full @SpringBootTest/Testcontainers-based integration tests at the top, covering the most critical end-to-end paths where the interaction between layers genuinely needs to be verified together.

How do you test asynchronous or scheduled code in Spring Boot?

Testing @Async methods typically means either calling the method and using a mechanism like Awaitility (or a CountDownLatch/CompletableFuture) to wait for the asynchronous work to actually complete before asserting on its effects, since a naive immediate assertion right after the call would race against the background thread. Testing @Scheduled methods usually means extracting the method's actual logic into a plain, directly-callable method invoked by a thin @Scheduled wrapper, so the test can call the logic method directly and synchronously rather than waiting for the real cron/fixed-rate trigger to fire.

Testing Spring Boot Applications

Slice tests, MockMvc, Testcontainers, and finding the right balance between unit and integration coverage.

Difficulty

Open as page

Spring Boot's testing support offers a spectrum from "test everything, realistically" to "test just this one layer, fast":

@SpringBootTest boots the full ApplicationContext (or close to it) — every bean, every auto-configuration, exactly as the real application would start:

@SpringBootTest
class OrderServiceIntegrationTest {
    @Autowired OrderService orderService;
    @Autowired OrderRepository orderRepository;

    @Test
    void createsAndPersistsAnOrder() {
        Order order = orderService.createOrder(new CreateOrderRequest(...));
        assertThat(orderRepository.findById(order.getId())).isPresent();
    }
}

This gives the most realistic test — closest to how the application actually behaves in production — but comes at a real cost: booting the entire context is comparatively slow, and a test only checking, say, controller-to-service wiring doesn't need the entire persistence layer, security configuration, and every other bean loaded just to verify that.

"Slice" test annotations load only the auto-configuration relevant to one specific architectural layer, leaving everything else out:

@WebMvcTest(OrderController.class) — auto-configures Spring MVC infrastructure (MockMvc, message converters, validation) and scans just the specified controller(s), without starting a real embedded server or wiring up the persistence layer, security beans, etc.

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired MockMvc mockMvc;
    @MockitoBean OrderService orderService; // service layer replaced with a mock — not a real bean

    @Test
    void returns404WhenOrderNotFound() throws Exception {
        when(orderService.getOrder(99L)).thenThrow(new OrderNotFoundException(99L));
        mockMvc.perform(get("/orders/99")).andExpect(status().isNotFound());
    }
}

@DataJpaTest — auto-configures an in-memory (or Testcontainers-backed) database, Spring Data repositories, and the EntityManager, without the web layer at all — great for testing repository query behavior in isolation.
@JsonTest — auto-configures just Jackson's ObjectMapper and related JSON serialization infrastructure, for testing custom serializers/deserializers without any web or persistence concerns.

Practical guidance: reach for the narrowest slice annotation that actually exercises what a given test cares about — it runs faster and fails with a clearer, more targeted signal when something's wrong — and reserve @SpringBootTest for genuinely full end-to-end integration tests where the interaction between multiple layers is specifically what's being verified.

Related Resources

Testing

Open as page

MockMvc lets you test Spring MVC controllers by simulating the request-dispatch mechanism itself — routing, argument resolution, message conversion, exception handling — without starting a real embedded server or making an actual network call, which makes it both fast and focused purely on the web layer's behavior.

Typical setup with @WebMvcTest:

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired MockMvc mockMvc;
    @MockitoBean OrderService orderService; // real service replaced with a mock for this test

    @Test
    void createOrder_returnsCreatedOrderWithLocationHeader() throws Exception {
        Order created = new Order(1L, "PENDING");
        when(orderService.create(any())).thenReturn(created);

        mockMvc.perform(post("/orders")
                .contentType(MediaType.APPLICATION_JSON)
                .content("""
                    {"customerId": "cust-1", "quantity": 2}
                    """))
            .andExpect(status().isCreated())
            .andExpect(header().string("Location", "/orders/1"))
            .andExpect(jsonPath("$.id").value(1))
            .andExpect(jsonPath("$.status").value("PENDING"));
    }

    @Test
    void getOrder_returns404WhenMissing() throws Exception {
        when(orderService.getOrder(99L)).thenThrow(new OrderNotFoundException(99L));

        mockMvc.perform(get("/orders/99"))
            .andExpect(status().isNotFound());
    }
}

Key building blocks:

perform(...) builds and dispatches a simulated request (get, post, put, delete static helpers from MockMvcRequestBuilders), with fluent methods for headers, body content, and request parameters.
andExpect(...) chains assertions on the result — HTTP status (status().isOk()), headers (header().string(...)), and response body content, including jsonPath(...) for asserting on specific fields within a JSON response without deserializing it into a full object first.
@MockitoBean (the modern replacement for the deprecated @MockBean) swaps out a real collaborator bean (here, OrderService) for a Mockito mock within the test's slice of the ApplicationContext, letting the test isolate the controller's own behavior (routing, validation, serialization, error handling) from the actual business logic underneath.

Why this is preferable to spinning up a real server and making real HTTP calls for most controller tests: it's dramatically faster (no real server startup, no real sockets/ports), and it still exercises the genuine Spring MVC dispatch pipeline (validation, exception handling, JSON serialization) — closer to a true integration test of the web layer than calling the controller method directly in plain Java would be, while remaining much cheaper than a full @SpringBootTest with a real running server.

Open as page

Both ultimately create a Mockito mock object, but they differ in whether that mock is registered inside a Spring ApplicationContext:

Plain Mockito.mock(SomeType.class) creates a mock with no Spring involvement whatsoever — appropriate for a pure, Spring-free unit test where you construct the class under test directly:

@Test
void placesOrderSuccessfully() {
    PaymentGateway mockGateway = mock(PaymentGateway.class); // plain Mockito, no Spring context at all
    when(mockGateway.charge(any(), any())).thenReturn(true);

    OrderService service = new OrderService(mockGateway); // constructed directly, not via Spring
    assertTrue(service.placeOrder(new Order(...)));
}

This is the fastest possible test — no ApplicationContext loads at all — and is exactly the kind of test constructor injection is specifically designed to make easy (see the constructor-injection question).

@MockitoBean (the current annotation; @MockBean served the same purpose in older Spring Boot versions and is now deprecated in favor of it) is used inside a Spring test context — it creates a Mockito mock and registers it as a bean in the test's ApplicationContext, replacing whatever real bean of that type would otherwise have been created/wired there:

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired MockMvc mockMvc;

    @MockitoBean
    OrderService orderService; // Spring wires this mock into OrderController instead of a real OrderService

    @Test
    void ...() throws Exception {
        when(orderService.getOrder(1L)).thenReturn(new Order(1L, "PENDING"));
        mockMvc.perform(get("/orders/1")).andExpect(status().isOk());
    }
}

When you need @MockitoBean instead of plain mock(): whenever the class under test is itself resolved and injected by Spring rather than constructed directly by your test code — e.g., testing a controller via MockMvc inside a @WebMvcTest, where OrderController is instantiated by the Spring test context and needs its OrderService dependency supplied through that same context, not through a constructor call your test code controls directly.

Rule of thumb: default to plain Mockito.mock() plus direct object construction wherever possible (it's simpler and faster); reach for @MockitoBean specifically when the object under test is managed by a Spring test context and you need to replace one of its dependencies within that context.

Open as page

A long-standing tension in integration testing: testing against a real database/message broker gives high confidence, but historically meant either maintaining a shared test environment (fragile, hard to keep clean between test runs, a source of flaky tests from shared state) or substituting a lighter-weight in-memory stand-in (e.g., H2 configured to mimic PostgreSQL) — which inevitably behaves subtly differently from the real production database in edge cases (specific SQL dialect features, constraint enforcement details, data type quirks).

Testcontainers solves this by spinning up real, disposable Docker containers of the actual external dependency, scoped to the test run itself — a genuine PostgreSQL, Kafka, Redis, or Elasticsearch instance, started fresh before the tests run and torn down afterward, with no persistent shared infrastructure to maintain:

@SpringBootTest
@Testcontainers
class OrderRepositoryIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16");

    @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);
    }

    @Autowired OrderRepository orderRepository;

    @Test
    void savesAndRetrievesAnOrder() {
        Order saved = orderRepository.save(new Order(...));
        assertThat(orderRepository.findById(saved.getId())).isPresent();
    }
}

Why this is a genuine improvement over an in-memory substitute:

Real behavioral fidelity — the test runs against the actual database engine (same SQL dialect, same constraint behavior, same JSON/array column support if used) that production uses, catching bugs an H2-based test would miss entirely.
Works for more than just databases — Testcontainers modules exist for Kafka, RabbitMQ, Redis, Elasticsearch, and many other common infrastructure dependencies, letting integration tests exercise messaging or caching behavior against the real thing too.
Fully automated and reproducible — each test run gets a clean, freshly-started container; there's no shared state to accidentally leak between test runs or between developers' machines, and no manually-provisioned test environment to keep in sync with production versions.

Practical trade-off: Testcontainers tests are slower than pure in-memory or mocked tests (starting a real container takes real time), so they're best reserved for a focused set of genuine integration tests — verifying repository queries, migration scripts, or messaging integration against the real technology — rather than being used for every single test in the suite; unit tests with plain mocks remain the right tool for testing business logic in isolation.

Related Resources

Testcontainers

Open as page

Database-backed integration tests face a classic isolation problem: if Test A inserts a row and it stays committed, Test B (or a later run of Test A itself) might see stale or conflicting data, unless every test carefully cleans up after itself.

Spring's test framework addresses this directly: annotating a test method or class with @Transactional wraps that test in a real database transaction that is, by default, automatically rolled back once the test completes — regardless of whether the test's own code ever explicitly commits, and regardless of whether the test passed or failed:

@SpringBootTest
@Transactional // every test method below runs in its own transaction, rolled back afterward
class OrderRepositoryTest {

    @Autowired OrderRepository orderRepository;

    @Test
    void savingAnOrderMakesItFindable() {
        Order saved = orderRepository.save(new Order(...));
        assertThat(orderRepository.findById(saved.getId())).isPresent();
        // no cleanup code needed — this insert is rolled back automatically after the test method returns
    }

    @Test
    void countIsUnaffectedByPreviousTest() {
        // starts from a clean slate — the previous test's insert never actually persisted
        assertThat(orderRepository.count()).isEqualTo(0);
    }
}

Why this matters for isolation: each @Test method gets its own transaction (started before the test, rolled back after), so tests never leak state into one another through the database — no manual DELETE FROM orders cleanup code, no ordering dependency between tests, and no risk of one test's leftover data silently breaking an unrelated test run later.

Important limitation to be aware of: this specifically tests behavior as observed from within a single transaction — it doesn't verify what actually happens once a transaction genuinely commits (e.g., whether a database trigger, a separate connection's read, or an actual cross-transaction concurrency scenario behaves correctly), since the rollback means nothing is ever really committed at all. For a test that specifically needs to verify true commit/cross-transaction behavior, you'd need to explicitly avoid the auto-rollback (e.g., via @Commit, used sparingly) or structure the test to genuinely span separate transactions.

Also worth noting: this rollback-based isolation happens at the database transaction level — it has no bearing on isolating things like static/shared in-memory state, external HTTP calls to third-party services, or message broker interactions, which need their own isolation strategy (mocking, Testcontainers with cleanup, etc.) regardless of @Transactional on the test.

Open as page

Tests frequently need different configuration than the real application — a test-only database URL, a disabled or stubbed-out external integration, relaxed security settings for convenience, or faster (if less secure) settings that would be inappropriate in production but are fine for a test run.

1. A dedicated test profile, with its own properties file:

src/test/resources/application-test.yml

spring:
  datasource:
    url: jdbc:h2:mem:testdb
logging:
  level:
    org.springframework: WARN

Activated on the test class:

@SpringBootTest
@ActiveProfiles("test") // loads application-test.yml on top of the base application.yml
class OrderServiceIntegrationTest { ... }

2. @TestPropertySource — set or override specific properties directly on the test class, without a separate profile-specific file:

@SpringBootTest
@TestPropertySource(properties = {
    "app.feature.new-checkout-flow.enabled=false",
    "spring.datasource.url=jdbc:h2:mem:testdb"
})
class CheckoutServiceTest { ... }

Can also point at a specific properties file: @TestPropertySource(locations = "classpath:test-specific.properties").

Both approaches layer on top of Spring Boot's normal configuration precedence — a test-specific property (whether from a profile-specific file or @TestPropertySource) overrides the base application.yml's value for that property, exactly as an active-profile file would in a non-test context, letting the same overall configuration-resolution model apply consistently to both production and test scenarios.

Practical guidance on choosing between them:

Use a dedicated application-test.yml + @ActiveProfiles("test") for a broader, reusable set of test-environment defaults shared across many test classes (e.g., "tests always use an in-memory database and disabled external calls").
Use @TestPropertySource for a small number of property overrides specific to one particular test class's needs, where creating an entire separate profile file would be overkill.

Both are commonly combined with @DynamicPropertySource (seen in the Testcontainers example) when a property's value isn't known statically ahead of time — e.g., a Testcontainers-assigned random port — since @TestPropertySource/profile files can only hold static values known at compile/config time.

Open as page

A common anti-pattern is defaulting to @SpringBootTest for nearly everything, because it's the most "realistic" option — but this produces a slow, expensive test suite where most tests don't actually need the full context they're paying for. A more deliberate, layered strategy (the classic "test pyramid" shape) tends to work better in practice:

Base — plain unit tests (most numerous, fastest): test business logic in isolation, with the class under test constructed directly (new OrderService(mockGateway, mockRepo)) and its collaborators replaced with plain Mockito mocks — no Spring context loads at all. This is exactly what constructor injection is designed to make trivial, and is where the bulk of business-logic edge cases, branching logic, and validation rules should be covered, since these tests run in milliseconds and give the fastest possible feedback.

Middle — slice tests (moderate number): verify each layer's Spring-specific wiring and behavior using the narrowest slice annotation that fits — @WebMvcTest for controller request/response handling, exception mapping, and validation; @DataJpaTest for repository query correctness (derived queries, @Query methods, entity mapping) against a real (often Testcontainers-backed) database. These catch integration mistakes specific to the framework layer (a malformed @RequestMapping, an incorrect JPQL query) that pure unit tests, with everything mocked out, wouldn't catch.

Top — full integration tests (fewest, most expensive): @SpringBootTest (optionally combined with Testcontainers and a real HTTP client like TestRestTemplate/WebTestClient) exercising a complete, realistic request flow end-to-end — reserved for the most critical user-facing paths (e.g., "placing an order end-to-end actually charges the customer and persists the order"), not every possible code path, since each of these tests is comparatively slow and expensive to run and maintain.

Why this shape, rather than "just use @SpringBootTest everywhere":

Speed of feedback — a large suite of full-context integration tests can turn a few-second test run into a multi-minute one, which directly slows down the development/CI feedback loop.
Failure locality — when a narrowly-scoped unit or slice test fails, the cause is usually obvious and localized; a failure in a large @SpringBootTest covering many layers at once gives a much vaguer signal about where the actual problem lies.
Genuine value of each layer — unit tests catch business-logic bugs cheaply; slice tests catch framework-wiring bugs; full integration tests catch the (hopefully rarer) bugs that only manifest from the interaction of multiple correctly-tested layers together — each layer is pulling its own weight rather than duplicating the same coverage at increasing cost.

Open as page

Both @Async and @Scheduled methods run outside the calling thread's normal, synchronous control flow, which means naive test assertions immediately following a call to one of them will often race against work that hasn't actually finished yet.

Testing @Async methods:

A test that calls an @Async method and immediately asserts on its side effects is racing against a background thread:

@Test
void sendsWelcomeEmailAsync() {
    userService.registerAndNotify(newUser); // returns immediately — @Async method runs on another thread
    assertThat(emailSender.wasCalled()).isTrue(); // FLAKY — might run before the async method actually completes
}

Common fixes:

Have the method return a CompletableFuture/Future, and .get() (or .join()) on it in the test — this blocks until the async work genuinely completes, giving a deterministic test:

CompletableFuture<Void> future = userService.registerAndNotifyAsync(newUser);
future.get(2, TimeUnit.SECONDS); // blocks until done, with a timeout as a safety net
assertThat(emailSender.wasCalled()).isTrue();

Use Awaitility to poll for an expected condition with a timeout, when the method's return type can't easily be changed to something awaitable:

await().atMost(2, TimeUnit.SECONDS).untilAsserted(() ->
    assertThat(emailSender.wasCalled()).isTrue());

Configure a synchronous TaskExecutor for the test profile — for tests where the asynchronous timing genuinely doesn't matter, swapping in a same-thread executor (e.g., Spring's SyncTaskExecutor) just for tests removes the asynchrony entirely, making the method effectively synchronous and simplifying the test — though this doesn't verify actual concurrent behavior, only the logic itself.

Testing @Scheduled methods:

Waiting for a real cron/fixed-rate trigger to fire in a test is slow and awkward. The standard approach is to extract the actual logic into a plain, directly-callable method, with the @Scheduled annotation on a thin wrapper that just delegates to it:

@Component
class ReportGenerator {
    @Scheduled(cron = "0 0 1 * * *")
    void scheduledRun() {
        generateDailyReport(); // thin wrapper — the annotation itself isn't what needs testing
    }

    void generateDailyReport() { /* the actual logic under test */ }
}

@Test
void generatesDailyReportCorrectly() {
    reportGenerator.generateDailyReport(); // call the logic directly and synchronously — no waiting for a trigger
    // assert on the report's contents
}

This tests the actual business logic thoroughly and quickly, while the @Scheduled wrapper itself (just "does this run on the intended schedule") is a thin enough layer that it's usually left unverified by automated tests, or checked separately via a lightweight scheduling-configuration review rather than by literally waiting for a cron trigger to fire during a test run.