Integration Testing: @SpringBootTest and Slice Tests

Integration testing exists to kill one very specific embarrassment: all unit tests green, production explodes. In a unit test you new the objects yourself and hand them fake collaborators; in production the objects are whatever the container assembled. Nobody ever verified that middle stretch — "did the parts actually get bolted together". Integration tests let the container really assemble once; slice tests assemble only the small region you want to check.

Five words, one line each (used throughout):

• ApplicationContext: Spring's housekeeper that creates and manages every object; starting it means assembling the whole application's parts
• Slice test: an annotation that loads only one layer — @WebMvcTest takes the web layer, @DataJpaTest takes JPA
• MockMvc: sends no real network traffic; it feeds a pretend request into Spring MVC's front door and walks routing → argument binding → serialization
• TestContext: the scheduler inside Spring Test that prepares the context, injects fields, runs callbacks and handles rollback — everything automated happens around it
• Context cache: tests with identical configuration reuse one context; change one thing in the key and it is rebuilt from scratch

After this article you should be able to answer three questions:

• Should my case use @SpringBootTest, @WebMvcTest or @DataJpaTest — and what is the decision criterion?
• Why did adding one @MockitoBean triple the runtime of the whole suite?
• @Transactional tests roll back automatically, so how can that hide a real unique-constraint bug?

The previous article showed the power of unit tests — millisecond verification of business branches. But they have a built-in blind spot: a mock only answers per your script and never misbehaves. So three classes of problems pass all unit tests and blow up in production:

• Wiring errors: your test does new UserService(mockRepo) and is perfectly green; at real startup the container holds two UserRepository implementations, neither with a @Qualifier, and it throws NoSuchUniqueBeanDefinitionException. You tested an object; runtime uses the container.
• SQL errors: the mocked repository always returns data, while the real @Query uses a field named username although the entity property is actually userName. A unit test never parses that JPQL, until the endpoint returns a 500 on first call.
• Serialization errors: a DTO carries a LocalDateTime with no JavaTimeModule registered. A unit test skips JSON serialization, until a real HTTP response fails to write with InvalidDefinitionException.

What these share is the point: the problem is not in the business logic but in how components are assembled. That is exactly the domain of integration and slice tests.

@SpringBootTest does one thing: start a real Spring application context and wire up everything it should. Its two most-used attributes are:

webEnvironment has four modes that differ a lot; choosing wrong costs you either "it will not start" or "twice as slow":

Beyond the main config, @TestConfiguration lets you add beans that exist only in tests — say a fake SMS client:

What a test environment needs is really just a variant of the production config: embedded database instead of the real one, schema handed to Hibernate, a profile of its own. Instead of copy-pasting somebody's src/test/resources/application.yml, tick the boxes and see which lines come out — and what breaks when you untick each one:

The most annoying part of integration tests is "data pollution" — data inserted by case A affects case B. Spring Test offers a neat fix: annotate the test class with @Transactional and every test method rolls back when it finishes.

Why can it roll back? Spring Test opens a transaction around the test method and binds it to the current thread's ThreadLocal, so every operation in the test reuses that one connection, and the framework rolls it back afterwards. This also hides two traps:

• It does not work for real HTTP under RANDOM_PORT: the HTTP request runs on a server thread, which cannot see the connection bound to the test thread, so the request's writes are not in the test transaction and will not roll back.
• It masks constraint problems: because the data is finally rolled back, foreign key and unique-constraint issues may surface only at flush time, or never.

That "same thread works, other thread leaks" boundary is not something prose makes stick. This animation runs the whole life of the framework's transaction — watch frame 6, where the rows it writes are never rolled back by anybody:

Now spread it out as a single-step run. The six lines on the left are what this test really executes; the right panel refreshes the variables and the call stack as you go. Step through and watch two moments: beat 3, where the service thinks it committed, and beat 6, where the thread name changes:

That line about "the service's commit is only a vote" can be watched directly in the kernel — same @Transactional, different propagation, different ending:

MOCK mode starts no server, but you can feed a request into the DispatcherServlet with MockMvc and walk the whole MVC flow:

MockMvc does not traverse the real network stack. To verify real HTTP behaviour (filters, serialization, status handling), use RANDOM_PORT with a real client:

A full context is heavy. Most of the time you only want the "web layer" or the "JPA layer"; slice test annotations wire only the relevant components and load nothing else:

@WebMvcTest wires only the web layer, so the Service a controller depends on is not created — fill the gap with @MockBean:

The table above says what each slice loads, but on a real ticket you ask the opposite question: which lamp does this particular bug need? Play a round — pick a failure class on the left, then the cheapest tool that catches it on the right; a wrong pick explains itself immediately.

H2 is fast, but it has dialect differences from MySQL — native functions, ON DUPLICATE KEY, pagination syntax and column types can all mismatch. So a harsh reality appears: all green on H2, a syntax error the moment you switch to MySQL.

Testcontainers is blunt and effective — spin up a real MySQL in Docker for the tests:

How you create data decides how stable the tests are. Three approaches, ordered from least to most recommended:

• data.sql: executed automatically at startup, good for baseline data every class needs (such as dictionary tables). The downside is it is global and easily interferes.
• @Sql: names a script on a single method or class, precisely scoping the data, and can set executionPhase = BEFORE_TEST_METHOD.

In a pipeline, first tell the two commands apart:

The reason is Maven's two test plugins: **surefire runs Test (unit / slice) and failsafe runs IT (integration) bound to the verify phase**. So integration classes usually end in IT:

Integration tests should cover every link of the request chain; the demo below makes clear just how many components one request passes through:

Every piece of magic so far — auto-injection, auto-rollback, context reuse — comes from one engine: TestContext, Spring Test's scheduler, the object that runs the whole routine before and after the first line of test code you wrote. Its complete round trip is the animation from Section 0:

Map each step onto the annotations you know and the machinery stops being mysterious:

Seven rows is a lot to hold in your head, and "which round is slow" is not something reading teaches. This diagram turns the same round trip into something you can click, one box at a time — stop on boxes 2 and 3:

Walk those seven steps yourself — switch the arguments to see each difference:

The second argument of that same lab is the single most important lesson of this article:

• A cache hit costs almost nothing: test number 100 may take 5ms because it reuses what test number 1 built
• A split key means powering the building up again: one extra properties line or one different mock combination creates a new key
• So the engineering discipline is: write tests of the same kind with byte-identical configuration, and group the odd ones into one package instead of scattering them project-wide

First pin down what actually enters the fingerprint — everything in the left column changes the key, everything in the right column never does:

What turns this into intuition, though, is the cache capacity number. Boot keeps only eight contexts, and nobody on a CI box has ever mentioned it:

Two more things only TestContext explains. First, the transaction inside a test is not your service-layer @Transactional — the framework opens it before round 6 and rolls it back unconditionally in round 7:

Second, why a slice insists you supply your own mocks — the filtered-out components simply never entered the container:

In the previous article you new-ed the test class yourself; in an integration test, the object that builds things becomes TestContext. Refresh the pure-Mockito side first, then contrast it with the container side:

The closing piece: what an integration test really starts is the very same SpringApplication.run() you met in the startup article. The only differences are that it runs inside the test JVM and its state is rolled back rather than handed to the outside world:

Enough buttons — type the commands yourself. This console talks to the same in-browser Java kernel and every reply is computed there: start with beans to count what a full context wires, then work down the lab lines:

Choosing a test scope is not mysticism; it is one explicit trade — how much fidelity you want against how many seconds you will pay. The sandbox below puts the three choices side by side; switch one position and you see per-case cost, memory footprint, and whether a certain class of bug can be caught at all:

A warm-up question, straight from the context-cache trap in Section 9:

Now a combined question threading the rollback trap of Section 3 with the dialect gap of Section 7:

Beginners spend most of their stuck time just decoding messages. This table is ordered by the literal fragment, so you can search it verbatim:

That tip deserves a live run. Below is the most common @WebMvcTest failure scene — do not read the analysis, just click the frame you think is guilty:

Goal: run one complete "testing a controller" slice and see with your own eyes that the Service is absent from the container and a mock stands in.

Step one — pom.xml needs exactly one starter (everything else comes from the parent):

Step two — the controller and service under test:

Step three — the test class:

Step four — the command and the expected output:

Started in 1.94 seconds plus Tests run: 1 means you passed. Notice the startup banner contains no Tomcat started on port — a slice never starts a server, which is exactly why it is fast.

1. Add @SpringBootTest on top of that class. You will observe: Tomcat appears in the banner, wall-clock time rises, and the console gains the full-context assembly logs — and ask yourself what changed in the cache key.
2. Delete @MockitoBean UserService userService; and run. You will observe: Failed to load ApplicationContext whose caused-by reads NoSuchBeanDefinitionException: UserService — row five of the Section 15 table, live.
3. Copy the class as UserControllerSliceTest2, changing only the stubbed return value from alice to bob, then run the whole package. You will observe: almost no time increase (same key, context reused). Now add @TestPropertySource(properties = "server.port=0") to one of them and rerun — this time a second context is built. That is Section 10's two traps, quantified.

Create a "three-layer test skeleton": the same order endpoint tested once each with @WebMvcTest, @DataJpaTest, and @SpringBootTest + Testcontainers, plus a short README stating what each covers. Acceptance checklist:

• [ ] All three classes pass together under mvn verify, and the slice tests still pass alone under mvn test
• [ ] The web case asserts status code + JSON fields + at least one response header
• [ ] The JPA case verifies a real @Query (not a derived one) and calls flush() explicitly
• [ ] The full case starts a real MySQL via Testcontainers and sets @AutoConfigureTestDatabase(replace = NONE)
• [ ] One case proves the unique constraint: no @Transactional, cleanup via @Sql, and the second insert must fail
• [ ] You measured and recorded the per-case cost of all three tiers, roughly matching the shape of the Section 13 sandbox
• [ ] The README answers one sentence: "if only one full-context case could survive, which would you keep, and why?"