Testing RESTful APIs
Use `MockMvc` or `WebTestClient` to write comprehensive integration tests for your Spring Boot REST controllers.
Testing RESTful APIs is a free Testing Mastery: JUnit, Mockito & Integration Tests lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Testing Mastery: JUnit, Mockito & Integration Tests learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Test REST APIs?
RESTful APIs are the backbone of many modern applications. Testing them is crucial to ensure they work as expected, handle various inputs, and return correct responses.
This lesson focuses on how to write integration tests for your Spring Boot REST controllers using powerful tools: MockMvc and WebTestClient.
Spring Boot Test Setup
To test Spring Boot controllers, we need a special setup. The @SpringBootTest annotation loads the full application context, and @AutoConfigureMockMvc configures MockMvc for us.
Here's a basic structure for a controller test class:
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;
@SpringBootTest
@AutoConfigureMockMvc
public class MyApiControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
void contextLoads() {
// Your tests will go here
}
}Introducing MockMvc
MockMvc allows you to test your Spring MVC controllers without starting a full HTTP server. It simulates HTTP requests and responses, making tests fast and isolated.
It's ideal for testing the controller layer, ensuring routes, request mappings, and response formats are correct.
MockMvc: Testing GET Requests
Let's test a simple GET endpoint, for example, /api/hello which returns "Hello, CoddyKit!". We'll verify the HTTP status code and the response content.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
// Assume a @RestController with @GetMapping("/api/hello") returning "Hello, CoddyKit!"
@SpringBootTest
@AutoConfigureMockMvc
public class HelloControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
void testHelloEndpoint() throws Exception {
mockMvc.perform(get("/api/hello"))
.andExpect(status().isOk())
.andExpect(content().string("Hello, CoddyKit!"));
}
}MockMvc: GET with Path Variables
APIs often use path variables to identify resources, like /api/users/{id}. MockMvc handles these naturally.
Here's how to test an endpoint that takes an ID:
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
// Assume @GetMapping("/api/users/{id}") returns "User: " + id
@SpringBootTest
@AutoConfigureMockMvc
public class UserControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
void testGetUserById() throws Exception {
mockMvc.perform(get("/api/users/{id}", 123))
.andExpect(status().isOk())
.andExpect(content().string("User: 123"));
}
}MockMvc: Testing POST Requests
For POST requests, you typically send a request body, often in JSON format. We can specify the content type and body using MockMvc.
Let's test an endpoint that creates an item:
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
// Assume @PostMapping("/api/items") creates an item and returns it
@SpringBootTest
@AutoConfigureMockMvc
public class ItemControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
void testCreateItem() throws Exception {
String newItemJson = "{\"name\":\"Laptop\", \"price\":1200}";
mockMvc.perform(post("/api/items")
.contentType(MediaType.APPLICATION_JSON)
.content(newItemJson))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.name").value("Laptop"));
}
}Introducing WebTestClient
WebTestClient is a non-blocking, reactive client for testing web applications. It's part of Spring WebFlux but can also be used to test Spring MVC controllers.
- It can perform actual HTTP calls (if configured to hit a running server).
- It can also be backed by
MockMvcfor server-side testing similar toMockMvcitself, but with a reactive API.
WebTestClient in Action
Using WebTestClient is similar to MockMvc, but its fluent API often feels more modern, especially for reactive applications. Let's re-test our /api/hello endpoint.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest;
import org.springframework.context.ApplicationContext;
import org.springframework.test.web.reactive.server.WebTestClient;
// For WebTestClient with Spring MVC, we can use @SpringBootTest
// and inject WebTestClient.Builder to build it with MockMvc.webAppContextSetup
// For simplicity, this example assumes a WebFlux app or WebTestClient set up for MockMvc
// @SpringBootTest
// class HelloWebClientTest {
// @Autowired WebApplicationContext wac;
// WebTestClient client;
// @BeforeEach void setup() { client = WebTestClient.bindToApplicationContext(wac).build(); }
// ...
// For a simpler runnable example focusing on WebTestClient usage:
@WebFluxTest // This annotation sets up a minimal reactive context for WebTestClient
public class HelloWebClientTest {
@Autowired
private WebTestClient webTestClient;
@Test
void testHelloEndpoint() {
webTestClient.get().uri("/api/hello")
.exchange()
.expectStatus().isOk()
.expectBody(String.class).isEqualTo("Hello, CoddyKit!");
}
}MockMvc vs. WebTestClient
When should you use MockMvc versus WebTestClient?
MockMvc: Best for traditional Spring MVC applications. It's server-side, simulates requests, and doesn't require a running server, making it fast.WebTestClient: Ideal for reactive Spring WebFlux applications. It also provides a reactive client API for testing Spring MVC apps, offering a more modern, fluent way to write tests, and can even hit a live server for true end-to-end integration tests.
For most Spring Boot REST API integration tests focusing on the controller layer, MockMvc is a solid choice due to its speed and direct integration.
Quick Check: API Testing Tools
You are building a Spring Boot application using traditional Spring MVC. You want to write fast, isolated integration tests for your REST controllers without starting a full HTTP server.
Recap & Next Steps
In this lesson, you learned how to write comprehensive integration tests for your Spring Boot REST controllers. We covered:
- Setting up your test environment with
@SpringBootTestand@AutoConfigureMockMvc. - Using
MockMvcto simulate GET and POST requests, verifying status and content. - Introducing
WebTestClientfor reactive testing and its alternative use cases. - Understanding the differences and when to choose between
MockMvcandWebTestClient.
These tools are essential for building robust and reliable RESTful APIs!
Frequently asked questions
Is the “Testing RESTful APIs” lesson free?
Yes — the full text of “Testing RESTful APIs” is free to read here on the web, and the Testing Mastery: JUnit, Mockito & Integration Tests course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Testing Mastery: JUnit, Mockito & Integration Tests course, upgrade to CoddyKit PRO.
What will I learn in “Testing RESTful APIs”?
Use `MockMvc` or `WebTestClient` to write comprehensive integration tests for your Spring Boot REST controllers. You practise Testing Mastery: JUnit, Mockito & Integration Tests with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Testing Mastery: JUnit, Mockito & Integration Tests?
No prior experience is required. Testing Mastery: JUnit, Mockito & Integration Tests on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Testing RESTful APIs” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Testing Mastery: JUnit, Mockito & Integration Tests lesson?
Yes. Every Testing Mastery: JUnit, Mockito & Integration Tests lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.