skip to content

What are the ways to create a MockMvcTester, and how do create(), from(), and of() differ?

level: middleimportance: should knowfreq 45%

answer

  1. create(mockMvc) = wrap existing
  2. from(context) = webAppContextSetup equivalent
  3. of(controllers) = standaloneSetup equivalent
  4. Boot 3.4 auto-config injectable bean
  5. standalone misses @ControllerAdvice unless registered

basics

~10 s

Three factories: MockMvcTester.create(mockMvc) wraps an existing MockMvc; MockMvcTester.from(webApplicationContext) builds one from the full context; MockMvcTester.of(controllers...) does a standalone setup with just the given controllers. Spring Boot 3.4+ also auto-configures an injectable bean.

solid answer

~40 s

MockMvcTester is a facade, so you create it around a MockMvc engine three ways. MockMvcTester.create(MockMvc) wraps a MockMvc you already built — useful when migrating existing setup. MockMvcTester.from(WebApplicationContext, optional customizer) builds from the full web context, loading real filters, converters, and controller advice — the equivalent of webAppContextSetup. MockMvcTester.of(controllers..., optional customizer) is a lightweight standalone setup that registers only the listed controller instances with minimal infrastructure — the equivalent of standaloneSetup, fast and focused but missing context-wide beans. With Spring Boot 3.4+, @WebMvcTest and @AutoConfigureMockMvc auto-configure a MockMvcTester bean you can @Autowired directly, so you rarely call the factories by hand in Boot apps. You can further customize (default headers, HttpMessageConverters for bodyJson) via with... methods on the returned instance.

code

java · 13 lines
java
// 1) Wrap an existing MockMvc
MockMvcTester mvc = MockMvcTester.create(existingMockMvc);

// 2) From the full web context (real filters, advice, converters)
MockMvcTester mvc2 = MockMvcTester.from(webApplicationContext,
        builder -> builder.defaultRequest(get("/").accept(APPLICATION_JSON)).build());

// 3) Standalone — only these controllers
MockMvcTester mvc3 = MockMvcTester.of(new UserController(service));

// 4) Spring Boot 3.4+ slice test — just inject it
// @WebMvcTest(UserController.class)
// class Tests { @Autowired MockMvcTester mvc; }

go deeper

for a junior

Know that you need a MockMvc engine and that Boot can inject a MockMvcTester for you.

for a middle

Explain create vs from vs of and map them to webAppContextSetup/standaloneSetup.

for a senior

Reason about which to pick per test type and how customizers wire security/converters/advice.

for a principal

Set team conventions: slice tests via auto-config, standalone for focused controller tests, and consistent converter config.

## The factories MockMvcTester is a **facade** over a `MockMvc` instance; you must give it an engine. There are three static factory methods plus Boot auto-configuration. ### 1. `MockMvcTester.create(MockMvc mockMvc)` Wraps an **already-built** `MockMvc`. Handy when you have existing setup code (`MockMvcBuilders.webAppContextSetup(ctx).apply(springSecurity()).build()`) and want the fluent API on top without rewriting it. This is the primary migration path from classic MockMvc. ### 2. `MockMvcTester.from(WebApplicationContext context)` Builds a MockMvcTester from the **full web application context** — the analogue of `MockMvcBuilders.webAppContextSetup(context)`. It loads the real Spring MVC infrastructure: registered `Filter`s, `HttpMessageConverter`s, `@ControllerAdvice`, argument resolvers, interceptors, etc. There's an overload accepting a `Function<DefaultMockMvcBuilder, MockMvc>` customizer so you can apply things like Spring Security's `SecurityMockMvcConfigurers.springSecurity()` or set default request properties. Use this for integration-style slice tests where you want context-wide behavior. ### 3. `MockMvcTester.of(Object... controllers)` / `of(Collection<?> controllers, Function<StandaloneMockMvcBuilder, MockMvc> customizations)` A **standalone** setup — the analogue of `MockMvcBuilders.standaloneSetup(controller)`. It registers only the controller instances you pass, with minimal, hand-configured infrastructure. It is fast and isolated (no full context load) but you must manually register any `@ControllerAdvice`, converters, or validators you need via the customizer. Good for focused unit-ish controller tests. ### 4. Spring Boot 3.4+ auto-configuration With `@WebMvcTest` or `@AutoConfigureMockMvc`, Spring Boot auto-configures a `MockMvcTester` bean. You just inject it: `@Autowired MockMvcTester mvc`. This is the idiomatic path in Boot apps — you almost never call `create/from/of` yourself. ## Post-creation customization The returned `MockMvcTester` exposes fluent `with...` methods, e.g. `withHttpMessageConverters(...)` (so `.bodyJson()`/`.convertTo(...)` can (de)serialize with your Jackson setup) and `withDefaultHeader(...)`/default request customizations applied to every request. ## Choosing between them | Need | Use | |---|---| | Reuse existing MockMvc | `create(mockMvc)` | | Full context, real filters/advice | `from(context)` | | Just one/few controllers, fast | `of(controllers...)` | | Spring Boot slice test | inject the auto-configured bean | ## Gotchas - Standalone `of(...)` will **not** pick up your `@ControllerAdvice` exception handlers unless you register them in the customizer — a common cause of "expected 400 but got 500". - `from(context)` requires a loaded `WebApplicationContext` (e.g., under `@SpringBootTest` or an MVC slice), so it's heavier than standalone. - If `.bodyJson().convertTo(MyType.class)` misbehaves, check that the tester uses the same `HttpMessageConverters` as production (configure via `withHttpMessageConverters`).

  • Your standalone of(...) test gets 500 instead of the 400 your @ControllerAdvice produces. Why?
    Standalone setup registers only the controllers you pass and no context-wide beans, so your @ControllerAdvice/@ExceptionHandler isn't applied. Register it via the of(...) customizer (setControllerAdvice(...)), or switch to from(context)/an auto-configured bean.
  • Which factory best supports Spring Security test configurers?
    from(WebApplicationContext, customizer) — apply SecurityMockMvcConfigurers.springSecurity() in the customizer — or wrap a MockMvc already built with security via create(...).

saying these in an interview costs you the question

  • Assuming standalone of(...) picks up @ControllerAdvice automatically
  • Thinking from() and of() are interchangeable regardless of test type
  • Not realizing Boot auto-configures the bean

context

resolving links…