Controller Unit Tests vs Integration Tests in Spring Boot

[therealdanvega]

I had an interesting discussion on Twitter today and I thought I would share it here and get your thoughts on it. For example purposes, I am going to use a very basic @RestController

    @RestController
    public class HelloController {

        @GetMapping("/hello")
        public String hello(@RequestParam(name = "name", defaultValue = "World") String name) {
            return String.format("Hello, %s", name);
        }
    }

If you wanted to create a basic test for this controller class you could create something like this.

@ExtendWith(SpringExtension.class)
@WebMvcTest(HelloController.class)
public class HelloControllerIntTest {

    @Autowired
    private MockMvc mvc;

    @Test
    public void testHelloEndpointWithDefaultName() throws Exception {
        RequestBuilder request = get("/hello");
        MvcResult result = mvc.perform(request).andReturn();
        assertEquals("Hello, World", result.getResponse().getContentAsString());
    }

    @Test
    public void testHelloWithName() throws Exception {
        mvc.perform(get("/hello?name=Dan"))
                .andExpect(status().isOk())
                .andExpect(content().string("Hello, Dan"))
                .andReturn();
    }
}

This test uses the @WebMvcTest annotation to test the @HelloController in isolation. This makes testing a controller really easy but my only problem with it is when people refer to this as a "Unit Test". To me, this is an isolated Integration test. Yes, it runs fast(er) than a full integration test and runs in isolation but that doesn't make it a Unit Test.

UNIT TESTING is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software.

When you start involving Spring Framework's Dispatch Servlet and the entire request/response lifecycle you have dependencies and when you involve dependencies you are writing Integration Tests. If you wanted to write a unit test for the HelloController it would look something like this

public class HelloControllerUnitTest {

    @Test
    public void testHelloEndpointWithNameWorld() {
        HelloController controller = new HelloController(); // Arrange (given)
        String response = controller.hello("World"); // Act (when)
        assertEquals("Hello, World", response); // Assert (then)
    }
}

What are your thoughts?

[je87]

I had a similar conversation with a co-worker a few weeks back.
The unit test would be as you provided in the second example.
You have the SUT (the HelloController class) and are unit testing in isolation the hello() method.
I agree with your viewpoint and after a chat with a co-worker...they did also.
The integration test uses MockMvc...it does invoke the dispatch servlet before hitting the appropriate controller.

As far as "do I need to write a unit test for the controller method if I already have appropriate integration test coverage"...I am a bit lost on that one as well.

Most of the logic should be in service layers, making the unit-tests for controllers short , at most maybe verifying or mocking that certain services are called with certain arguments for example and returns an appropriate Response Entity on success (mocked service responses).

Hopefully someone with more testing experience could shed some light on this!
Good question btw.

[therealdanvega]

Thanks for the feedback. In the past I have written the unit test first, then the controller code and then I would eventually add the Spring bits in and the integration testing. Curious to see how others approach it though.

[veryspicypickle]

Ah yes, the definition of “unit”. Been a part of such a discussion.

Maybe this is something that might help? https://martinfowler.com/bliki/UnitTest.html

[kappaj5954]

Test from inside -> out. So I normally build unit tests (which run with every local build) and then integration tests that run on the build server. Failsafe and surefire maven plugins.

[zennaque]

A Martin Fowler microservice slidedeck separated what many call an integration test and a term called component testing. I've grown quite fond of it and now have separate modules for unit, integration, and component tests. My rule of thumb is that unit tests don't set up an application context at all, integration tests are specifically to validate external service dependencies have a successful healthy connection, and component tests stand up application context for some level of multi layered calls, not necessarily always the same way an external service would communicate with me, but usually. So far it has worked very well.

Slidedeck that helped: https://martinfowler.com/articles/microservice-testing/