MockMvc, WebTestClient & Testcontainers in Depth — Interview Questions

How to use this lesson

These are hands-on questions. Show working snippets, and explain the speed and fidelity trade-offs: MockMvc (fast, in-process) vs a real server, and Testcontainers (realistic) vs embedded fakes.

Q1. What's the difference between MockMvc and WebTestClient?

Short answer:

• MockMvc: for Spring MVC (servlet). It runs in-process through a mock servlet request and response, with no network, and uses the ResultMatcher style (andExpect). Boot 3.4 adds MockMvcTester (AssertJ).
• WebTestClient: a fluent, non-blocking test client:
  • it tests WebFlux applications in-process (bindToApplicationContext, bindToController, bindToRouterFunction);
  • it can call a real server (bindToServer, or auto-configured with RANDOM_PORT);
  • since Spring 5.3, it can also drive MockMvc-based MVC applications (MockMvcWebTestClient);
  • it supports streaming assertions (returnResult(...).getResponseBody() with StepVerifier).

Choose MockMvc for MVC slice tests, and WebTestClient for WebFlux, real-server tests, or when you want one client style across stacks.

Q2. How do you test Spring Security-secured endpoints with MockMvc? How do you simulate an authenticated user with roles?

Short answer: With @WebMvcTest, the security filter chain is included (your SecurityFilterChain configuration, when imported; Boot applies it to the slice). Then:

@WebMvcTest(AdminController.class)
@Import(SecurityConfig.class)
class AdminSecurityTest {
    @Autowired MockMvc mvc;
    @MockitoBean AdminService service;

    @Test void anonymousGets401() throws Exception {
        mvc.perform(get("/api/admin/users")).andExpect(status().isUnauthorized());
    }
    @Test @WithMockUser(roles = "USER")
    void userWithoutAdminRoleGets403() throws Exception {
        mvc.perform(get("/api/admin/users")).andExpect(status().isForbidden());
    }
    @Test void adminWithJwtScopeGets200() throws Exception {
        mvc.perform(get("/api/admin/users").with(jwt().authorities(new SimpleGrantedAuthority("ROLE_ADMIN"))))
           .andExpect(status().isOk());
    }
    @Test void postNeedsCsrfForSessionAuth() throws Exception {
        mvc.perform(post("/admin/form").with(user("admin").roles("ADMIN")).with(csrf())).andExpect(status().is3xxRedirection());
    }
}

The simulation options are @WithMockUser, @WithUserDetails, custom @WithSecurityContext annotations, and the post-processors user(), jwt(), oauth2Login(), opaqueToken().

Q3. Can MockMvc test filters and interceptors?

Short answer: Yes.

• Interceptors registered through WebMvcConfigurer are part of the MVC slice, and run in MockMvc automatically.
• Servlet filters: @WebMvcTest and @AutoConfigureMockMvc add Spring-managed filter beans (including Spring Security's filter chain) to MockMvc. With a manual standalone setup, add them explicitly: MockMvcBuilders.standaloneSetup(controller).addFilters(new CorrelationIdFilter()).addInterceptors(...).
• Assert their effects: response headers (a correlation ID), rejections (401 or 429 from a rate-limit filter), and MDC or request attributes.
• The limitation: container-level behaviour (Tomcat valves, error pages, DispatcherType.ERROR flows) needs a real server test.

Q4. How do you test a PATCH request with MockMvc?

Short answer:

mvc.perform(patch("/api/products/{id}", ID)
        .contentType("application/merge-patch+json")          // or application/json-patch+json for RFC 6902
        .header(HttpHeaders.IF_MATCH, "\"v7\"")                // optimistic concurrency via ETag
        .content("""{"price": 1299.00, "description": null}""")
        .with(jwt()))
   .andExpect(status().isOk())
   .andExpect(jsonPath("$.price").value(1299.00))
   .andExpect(jsonPath("$.description").doesNotExist());

Test these semantics:

• omitted fields stay unchanged;
• explicit null clears a field (merge-patch semantics);
• validation errors give 400 or 422;
• an ETag mismatch gives 412 Precondition Failed;
• an unknown resource gives 404.

Q5. How do you assert JSON structure and content with jsonPath()?

Short answer:

.andExpect(jsonPath("$.id").value(ID.toString()))
.andExpect(jsonPath("$.lines", hasSize(2)))
.andExpect(jsonPath("$.lines[0].sku").value("SKU-1"))
.andExpect(jsonPath("$.lines[*].qty", everyItem(greaterThan(0))))
.andExpect(jsonPath("$.total").value(closeTo(250.0, 0.001)))
.andExpect(jsonPath("$.internalCost").doesNotExist())          // guard against leaking fields
.andExpect(jsonPath("$.status", is(oneOf("PAID", "PENDING"))))

For whole-document comparisons, use content().json(expectedJson, JsonCompareMode.LENIENT) (JSONassert), and use strict mode when extra fields must fail. Use @JsonTest slices to test serialisation rules separately (JacksonTester).

Q6. What's the difference between @WebMvcTest and testing with the full context?

Short answer:

• @WebMvcTest: only the web layer. Services are mocked. It's fast (a small context), with focused failures, but it can't catch wiring or transaction problems, or real serialisation of data coming from the database.
• The full context (@SpringBootTest + MockMvc, or a real server): real services, repositories and configuration, catching integration bugs. It's slower, needs infrastructure (Testcontainers), and failures are harder to localise.

Use both: many slice tests for the API contract and the error mapping, and fewer full-context tests for critical flows.

Q7. Can you test file uploads with MockMvc?

Short answer: Yes, with multipart(...) and MockMultipartFile parts (see the upload example in the previous lesson). Also test:

• missing parts give 400;
• size limits give 413 (configure spring.servlet.multipart.max-file-size in the test properties);
• invalid types are rejected;
• for PUT multipart, use multipart(HttpMethod.PUT, url) (Spring 5.3.22+).

For streaming large uploads or real container limits, test against a real server.

Q8. How does WebTestClient handle reactive endpoints? How do you test streaming (Flux) responses?

Short answer: WebTestClient subscribes to the reactive response, and supports:

• expectBody(Dto.class), expectBodyList(...);
• for streams, returnResult(Dto.class).getResponseBody(), which gives a Flux that you verify with StepVerifier: take N elements, check them, and cancel (important for infinite SSE streams);
• controlling Accept: text/event-stream, and asserting the Content-Type.

Flux<PriceTick> ticks = client.get().uri("/prices/stream?symbol=INFY")
        .accept(MediaType.TEXT_EVENT_STREAM).exchange()
        .expectStatus().isOk()
        .returnResult(PriceTick.class).getResponseBody();

StepVerifier.create(ticks.take(3))
        .expectNextMatches(t -> t.symbol().equals("INFY"))
        .expectNextCount(2)
        .verifyComplete();

Use virtual time (StepVerifier.withVirtualTime) for interval-based publishers, to avoid real waits.

Q9. What problem does Testcontainers solve, compared with H2?

Short answer: Fidelity. Testcontainers starts real dependencies in Docker, such as the same database engine and version as production, Kafka, RabbitMQ, Redis, Elasticsearch, LocalStack (AWS) and Keycloak, managed from the test code (started before tests, and cleaned up automatically by the Ryuk sidecar). Compared with H2 or other embedded fakes, you catch:

• dialect and feature differences (JSON types, window functions, native SQL, sequences);
• locking and isolation behaviour;
• real migrations (Flyway or Liquibase);
• broker semantics (partitions, transactions, DLTs);
• configuration issues, before production.

The costs: it needs Docker, the containers take seconds to start (use reuse or singletons), and it uses resources in CI.

Q10. How do you start a real PostgreSQL or MySQL container for tests? How do you override Spring Boot properties with container ports?

Short answer: Boot 3.1+ uses @ServiceConnection, which auto-configures the DataSource (or Kafka, Redis, Mongo…) from the container, with no property plumbing:

@TestConfiguration(proxyBeanMethods = false)
class TestcontainersConfig {
    @Bean @ServiceConnection
    PostgreSQLContainer<?> postgres() { return new PostgreSQLContainer<>("postgres:16-alpine"); }
}

@SpringBootTest
@Import(TestcontainersConfig.class)
class OrderFlowIT { /* the real DataSource points at the container */ }

Before 3.1, or for custom properties, use @DynamicPropertySource:

@Container static PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16-alpine");
@DynamicPropertySource
static void props(DynamicPropertyRegistry r) {
    r.add("spring.datasource.url", pg::getJdbcUrl);
    r.add("spring.datasource.username", pg::getUsername);
    r.add("spring.datasource.password", pg::getPassword);
    r.add("app.search.url", () -> "http://" + es.getHost() + ":" + es.getMappedPort(9200));   // mapped random port
}

Containers expose random mapped ports, so always read getMappedPort(...)/getHost(). Never hard-code them.

Q11. How do you reuse Testcontainers instances across test classes?

Short answer:

• The singleton container pattern: declare containers as static fields in an abstract base class, or a shared @TestConfiguration, and start them once per JVM (a static initialiser, or a bean-defined container that the Spring context cache shares). Every test class extending the base shares the container, and context caching keeps one Spring context.
• Bean-defined @ServiceConnection containers in a shared @TestConfiguration: the container lives as long as the cached context.
• Testcontainers reusable mode (.withReuse(true) plus testcontainers.reuse.enable=true in ~/.testcontainers.properties) keeps containers running between test runs locally, which is great for developer speed. It's not recommended in CI.
• Isolate the data between tests, with truncation or unique IDs, because the container state persists across classes.

Q12. How do you test Kafka or RabbitMQ with Testcontainers?

Short answer:

• Kafka: ConfluentKafkaContainer/KafkaContainer (KRaft mode, no ZooKeeper), with @ServiceConnection wiring spring.kafka.bootstrap-servers. Add Schema Registry containers on a shared Network if you use Avro.
• RabbitMQ: RabbitMQContainer, with @ServiceConnection.
• Test: produce or send through the real template → await the listener's side effect (Awaitility), or consume from the output or DLT with a test consumer. Also test retries and DLQ routing, ordering per key, consumer-group behaviour, transactions, and serialisation compatibility.
• Tips: use unique topic names per test (or clean up), shorten the consumer poll and retry backoff in the test properties, and set auto.offset.reset=earliest for test consumers.

Q13. Can Testcontainers be used with JUnit 5 dynamic tests (and other lifecycles)?

Short answer: Yes.

• @Testcontainers plus @Container fields manage the lifecycle with the JUnit 5 extension:
  • static fields: one container per class;
  • instance fields: one per test method.
• With @TestFactory dynamic tests, the extension's per-method lifecycle doesn't apply to each dynamic test (they share the factory method's lifecycle), so start the containers statically, or manually (container.start() in @BeforeAll, or in the factory), and generate dynamic tests that use them. For example, run the same test suite against several database versions by creating a container per version inside the factory.
• Parameterised tests work the same way (shared static containers).

Q14. How does Testcontainers detect whether Docker is running?

Short answer: At startup, Testcontainers runs a strategy chain to find a Docker environment:

• the DOCKER_HOST environment variable, and ~/.testcontainers.properties (docker.host);
• Unix socket (/var/run/docker.sock), or Windows named pipes;
• Docker Desktop, Colima or Rancher Desktop contexts;
• Testcontainers Cloud (a remote engine).

It then pings the Docker daemon through the Docker API, and checks the version and disk space. If none is found, it throws IllegalStateException: Could not find a valid Docker environment. To skip gracefully, use @Testcontainers(disabledWithoutDocker = true), or an assumption on DockerClientFactory.instance().isDockerAvailable().

Q15. How do you combine Testcontainers with Flyway or Liquibase?

Short answer: Nothing special is needed. With @ServiceConnection (or dynamic properties) pointing Spring's DataSource at the container, Boot's Flyway or Liquibase auto-configuration runs the real migrations at context startup, against the containerised database, exactly as in production. The best practices:

• spring.jpa.hibernate.ddl-auto=validate, to catch entity and schema drift;
• test-only data migrations in a separate location (spring.flyway.locations=classpath:db/migration,classpath:db/testdata);
• for migration testing specifically, test each version's upgrade (start from a snapshot of the previous schema);
• reset between classes with flyway.clean() + migrate() (enable clean only in tests, and never in production).

Q16. What are Testcontainers' limitations in CI environments?

Short answer:

• It needs Docker, and some CI runners forbid privileged Docker, or Docker-in-Docker. Solutions: Docker socket mounting, DinD services (GitLab), rootless Docker, Testcontainers Cloud, or Kubernetes-based runners with extra configuration.
• Startup time and resources: pulling images and starting containers adds minutes. Cache the images, pin small tags (-alpine), use singleton containers, and parallelise forks carefully (each fork starts its own containers, which uses memory and CPU).
• Networking quirks: use getHost()/getMappedPort(), and custom networks for container-to-container communication.
• Flakiness: proper wait strategies (log messages, health checks) are needed, and timeouts on slow CI machines.
• Architecture: ARM runners (Apple Silicon, Graviton) need multi-arch images.
• Rate limits on Docker Hub pulls: use a registry mirror.
• Reuse mode isn't suitable for CI.

Q17. How do you integrate Testcontainers with the Maven or Gradle build lifecycle?

Short answer:

• Separate unit and integration tests:
  • Maven: Surefire runs unit tests (*Test) in the test phase, and Failsafe runs integration tests (*IT) in integration-test plus verify (it fails the build after cleanup);
  • Gradle: a dedicated integrationTest source set and task (or the JVM Test Suite plugin), with check.dependsOn(integrationTest).
• Dependencies: org.testcontainers:* modules (through the Testcontainers BOM, or Spring Boot's dependency management), plus spring-boot-testcontainers.
• CI: run integration tests in pipeline stages that have Docker available, cache the images, and publish the test reports.
• Development-time use (Boot 3.1+): SpringApplication.from(App::main).with(TestcontainersConfig.class).run() (a TestApplication main class in src/test) runs the application locally with containers, with no local database install needed.

Follow-up questions this topic invites — and their answers

Q: Why did @WebMvcTest not load my service bean? A: Slices only include web components. Services must be mocked (@MockitoBean) or imported explicitly (@Import(MyService.class)). That's by design, to keep slice tests focused and fast.

Q: How do you make container startup faster? A: Use smaller images, singleton or shared containers, @ServiceConnection (no extra property plumbing), parallel startup (Startables.deepStart), and reusable mode locally. Keep container-based tests in their own suite, so unit tests stay fast.

Q: Is it OK to share one database container among parallel test classes? A: Yes, if the tests isolate their data (unique tenants or IDs, or schema-per-worker). Otherwise, parallel classes interfere. Many teams use one container per fork, plus truncation between classes.

Q: What's LocalStack used for? A: Emulating AWS services (S3, SQS, SNS, DynamoDB, Secrets Manager) in a container, so AWS SDK integrations can be integration-tested without real cloud resources.