Why MockMvc for HTTP assertions in Spring Boot? - Purpose & Use Cases

The Big Idea

What if you could test your web app's HTTP responses instantly and automatically every time you save code?

The Scenario

Imagine testing your web app by manually sending HTTP requests and checking responses in a browser or with external tools every time you change code.

The Problem

This manual testing is slow, repetitive, and easy to miss errors because you have to remember all the steps and expected results each time.

The Solution

MockMvc lets you write automated tests that simulate HTTP requests and check responses inside your code, making testing fast, repeatable, and reliable.

Before vs After

✗ Before

Start server, open browser, send GET request, check response manually

✓ After

mockMvc.perform(get("/api/data")).andExpect(status().isOk()).andExpect(content().string("expected"));

What It Enables

You can quickly verify your web endpoints behave correctly without running the full server or using external tools.

Real Life Example

When adding a new API endpoint, you write a MockMvc test to confirm it returns the right data and status code automatically on every code change.

Key Takeaways

Manual HTTP testing is slow and error-prone.

MockMvc automates HTTP request and response checks inside tests.

This leads to faster, more reliable web application testing.

Practice

1. What is the main purpose of using MockMvc in Spring Boot tests?

easy

A. To test HTTP requests and responses without starting a real server

B. To deploy the application to a production server

C. To generate HTML pages automatically

D. To manage database connections

Solution

1. Step 1: Understand MockMvc role

   MockMvc simulates HTTP requests and responses in tests without needing a real server.

2. Step 2: Compare options

   Options A, B, and D describe unrelated tasks like HTML generation, deployment, or database management.

3. Final Answer:

   To test HTTP requests and responses without starting a real server -> Option A

4. Quick Check:

   MockMvc = HTTP testing without server [OK]

Hint: MockMvc tests HTTP calls without running the server [OK]

Common Mistakes:

• Thinking MockMvc starts a real server
• Confusing MockMvc with deployment tools
• Assuming MockMvc manages databases

2. Which of the following is the correct way to perform a GET request using MockMvc?

easy

A. mockMvc.perform(get("/api/data"))

B. mockMvc.get("/api/data")

C. mockMvc.request("GET", "/api/data")

D. mockMvc.callGet("/api/data")

Solution

1. Step 1: Recall MockMvc syntax

   The correct syntax uses mockMvc.perform(get("/url")) with static import of get.

2. Step 2: Check other options

   Options B, C, and D use invalid method names not provided by MockMvc API.

3. Final Answer:

   mockMvc.perform(get("/api/data")) -> Option A

4. Quick Check:

   Use perform(get()) for GET requests [OK]

Hint: Use perform(get("url")) to send GET requests [OK]

Common Mistakes:

• Using mockMvc.get() directly
• Confusing method names like request() or callGet()
• Not importing static get() method

3. Given the following test snippet, what HTTP status code will be asserted?

mockMvc.perform(get("/hello"))
       .andExpect(status().isOk());

medium

A. 404 Not Found

B. 500 Internal Server Error

C. 200 OK

D. 302 Redirect

Solution

1. Step 1: Understand status().isOk()

   The method status().isOk() checks for HTTP status code 200.

2. Step 2: Match status codes

   200 means success, 404 means not found, 500 means server error, 302 means redirect.

3. Final Answer:

   200 OK -> Option C

4. Quick Check:

   status().isOk() = 200 OK [OK]

Hint: isOk() always means HTTP 200 success [OK]

Common Mistakes:

• Confusing isOk() with error codes
• Assuming isOk() means redirect
• Mixing status codes meanings

4. Identify the error in this MockMvc test code snippet:

mockMvc.perform(post("/submit"))
       .andExpect(status().isOk)
       .andExpect(content().string("Success"));

medium

A. Using post instead of get for /submit

B. Missing parentheses after isOk method call

C. Incorrect content matcher method name

D. No error, code is correct

Solution

1. Step 1: Check method calls

   The method isOk must be called with parentheses: isOk().

2. Step 2: Verify other parts

   Using post for /submit is valid; content().string() is correct; so no other errors.

3. Final Answer:

   Missing parentheses after isOk method call -> Option B

4. Quick Check:

   Method calls need parentheses like isOk() [OK]

Hint: Always add () after status check methods like isOk() [OK]

Common Mistakes:

• Forgetting parentheses on isOk()
• Confusing post and get methods
• Using wrong content matcher method

5. You want to test a JSON response from /user/1 endpoint that returns {"name":"Alice","age":30}. Which MockMvc assertion correctly checks the name field in the JSON response?

hard

A. andExpect(content().string("Alice"))

B. andExpect(content().json("name: Alice"))

C. andExpect(jsonPath("name").isEqualTo("Alice"))

D. andExpect(jsonPath("$.name").value("Alice"))

Solution

1. Step 1: Understand JSON path syntax

   To check JSON fields, use jsonPath("$.fieldName") with value() for expected value.

2. Step 2: Evaluate options

   andExpect(jsonPath("$.name").value("Alice")) uses correct syntax. andExpect(content().json("name: Alice")) has invalid JSON format. andExpect(jsonPath("name").isEqualTo("Alice")) uses wrong jsonPath syntax. andExpect(content().string("Alice")) checks whole string, not JSON field.

3. Final Answer:

   andExpect(jsonPath("$.name").value("Alice")) -> Option D

4. Quick Check:

   Use jsonPath("$.field").value() for JSON checks [OK]

Hint: Use jsonPath("$.field").value(expected) to check JSON fields [OK]

Common Mistakes:

• Wrong jsonPath syntax without $
• Trying to match JSON with plain string
• Using incorrect matcher methods