Unravel โบ Java concepts โบ Testing
Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)
These tools call your endpoints from a test and check status, headers and JSON body.
Learn these first
At a glance
A mystery shopper who walks into your shop, asks for things at the counter and writes down exactly what was said and handed back.
- 1mvc.perform(post("/orders").contentType(JSON).content(json)) builds a request; .andExpect(status().isCreated()) and .andExpect(jsonPath("$.id").value(1)) assert on the responseandDo(print()) shows the full exchange when a test fails.
- 2Security: with(jwt()), with(csrf()) and @WithMockUser(roles = "ADMIN") set up an authenticated user without logging in
- 3WebTestClient is the reactive counterpart: client.get().uri("/orders/1").exchange().expectStatus().isOk().expectBody().jsonPath("$.status").isEqualTo("NEW")
- 4RestAssured.given().body(x).when().post("/orders").then().statusCode(201).body("id", notNullValue()) reads like a specification and is common for end-to-end API tests
- MockMvc runs the dispatcher servlet in-process, so it does not test the servlet container, real HTTP, TLS or serialization over the wire
- Assert on the contract, not the whole body string
- MockMvc creates mock servlet request and response objects and calls the DispatcherServlet directly, passing through the filter chain you configured
mvc.perform(post("/orders") .contentType(MediaType.APPLICATION_JSON) .content("{\"sku\":\"A-100\",\"quantity\":2}") .with(jwt().authorities(new SimpleGrantedAuthority("SCOPE_orders.write")))) .andExpect(status().isCreated()) .andExpect(header().exists("Location")) .andExpect(jsonPath("$.quantity").value(2));- line 5 uses andExpect, the core of Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)
- line 6 uses andExpect, the core of Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)
- line 7 uses andExpect, the core of Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)
Read the full explanation (about 1 min)
These tools call your endpoints from a test and check status, headers and JSON body. MockMvc does it without a network server, WebTestClient works with or without one, and REST Assured is a fluent client for real running services.
A mental model
A mystery shopper who walks into your shop, asks for things at the counter and writes down exactly what was said and handed back. MockMvc does it inside the shop; REST Assured stands outside on the street.
How it works
mvc.perform(post("/orders").contentType(JSON).content(json)) builds a request; .andExpect(status().isCreated()) and .andExpect(jsonPath("$.id").value(1)) assert on the response. andDo(print()) shows the full exchange when a test fails.
Security: with(jwt()), with(csrf()) and @WithMockUser(roles = "ADMIN") set up an authenticated user without logging in.
WebTestClient is the reactive counterpart: client.get().uri("/orders/1").exchange().expectStatus().isOk().expectBody().jsonPath("$.status").isEqualTo("NEW").
RestAssured.given().body(x).when().post("/orders").then().statusCode(201).body("id", notNullValue()) reads like a specification and is common for end-to-end API tests.
Going deeper
MockMvc runs the dispatcher servlet in-process, so it does not test the servlet container, real HTTP, TLS or serialization over the wire. Keep a few real-port tests for those.
Assert on the contract, not the whole body string. Whole-string comparisons break on field order or whitespace; jsonPath or a JSON-compare mode (lenient) is more stable.
Test the error paths and the unauthorised case (401, 403, 404, validation 400), not just 200. These are where clients actually break.
Under the hood
MockMvc creates mock servlet request and response objects and calls the DispatcherServlet directly, passing through the filter chain you configured. There are no sockets: the mock response collects status, headers and body bytes in memory so that matchers can inspect them.
Common mistakes
- Only testing the happy path.
- Whole-body string equality.
- Assuming MockMvc covers real HTTP behaviour.
- Forgetting CSRF or authentication in secured endpoints.
How Unravel recognises it
When you paste code, Unravel looks for these signs of testing http endpoints (mockmvc, webtestclient, rest assured). Spotting them yourself is a good habit when you read unfamiliar code:
- Types:
MockMvcMockMvcRequestBuildersMockMvcResultMatchersMockHttpServletRequestMockHttpServletResponseWebTestClientRestAssuredResultActionsMvcResultMockMvcBuildersRequestPostProcessorSecurityMockMvcRequestPostProcessorsMockMultipartFileMockMvcTesterand 1 more - Method calls:
andExpect()andReturn()andDo()jsonPath()expectStatus()expectBody()
Part of a learning path
- Testing enterprise code ยท previous: Spring Boot test slices and test configuration ยท next: Testcontainers (real databases and brokers in tests)
Related concepts
Frequently asked questions
What is Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)?
These tools call your endpoints from a test and check status, headers and JSON body. MockMvc does it without a network server, WebTestClient works with or without one, and REST Assured is a fluent client for real running services.
What are the most common mistakes with Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured)?
Only testing the happy path. Whole-body string equality. Assuming MockMvc covers real HTTP behaviour. Forgetting CSRF or authentication in secured endpoints.
How can I see Testing HTTP endpoints (MockMvc, WebTestClient, REST Assured) in real code?
Paste your own Java into Unravel and it will point out where testing http endpoints (mockmvc, webtestclient, rest assured) appears, explain how it works at the detail level you choose, and draw the flow of the code around it.