Mockito – My Shitty Code

Mockito: Effective Partial Mocking

Shitty Author — Thu, 13 Mar 2014 18:52:17 +0000

Sometimes, we may only want to partially mock an object to unit test our code. There are several ways to skin this cat, but I’ll show two straightforward approaches that allow you to obtain the cat fur.

PROBLEM

Let’s assume we want to test this service class:-

public class CalculationService {

    public int getFirstValue() {
        return 1;
    }

    public int getSecondValue() {
        return 2;
    }

    public int getComputedValue() {
        return getFirstValue() + getSecondValue();
    }
}

Basically, getComputedValue() sums up getFirstValue() and getSecondValue() and returns the value.

PARTIAL MOCKING USING mock(…)

Here’s an example of using mock object:-

CalculationService calculationService = mock(CalculationService.class);
when(calculationService.getFirstValue()).thenReturn(2);
when(calculationService.getSecondValue()).thenReturn(5);

int val = calculationService.getComputedValue();

assertThat(val, is(???));

What do you think the value for ??? should be?

If you think the value is 7, you are not skinning the cat correctly.

The correct value is 0. In the above example, when we execute calculationService.getComputedValue(), we are actually executing a stub API from the mock object that doesn’t do anything but to return a default value, which is 0.

The good news is Mockito provides thenCallRealMethod() that allows us to execute the actual method instead. So, to fix this, we do something like this:-

CalculationService calculationService = mock(CalculationService.class);
when(calculationService.getFirstValue()).thenReturn(2);
when(calculationService.getSecondValue()).thenReturn(5);

when(calculationService.getComputedValue()).thenCallRealMethod();

int val = calculationService.getComputedValue();

assertThat(val, is(7));

PARTIAL MOCKING USING spy(…)

Another way to do partial mocking is to use a spy. Here’s an example:-

CalculationService calculationService = spy(new CalculationService());
when(calculationService.getFirstValue()).thenReturn(2);
when(calculationService.getSecondValue()).thenReturn(5);

int val = calculationService.getComputedValue();

assertThat(val, is(7));

WHICH IS A BETTER WAY?

It is difficult to say which approach is better because it all depends on the object we are testing. My rule of thumb is if we only want to modify the behavior of small chunk of API and then rely mostly on actual method calls, use spy(…). Otherwise, use mock(…).

In another word, when we start skinning a cat and it starts to bleed like crazy and scratch your face, sometimes, it’s wise to put down the knife and consider taking a different approach to solve the problem… metaphorically speaking.

The post Mockito: Effective Partial Mocking appeared first on My Shitty Code.

MockMvc + Mockito = Epic Tests

Shitty Author — Fri, 17 Jan 2014 00:37:22 +0000

Spring Framework 3.2 introduces a very elegant way to test Spring MVC controller using MockMvc.

Based on the documentation, there are two ways to configure MockMvc:-

MockMvcBuilders.webAppContextSetup(webApplicationContext).build()
MockMvcBuilders.standaloneSetup(controller).build()

The first approach will automatically load the Spring configuration and inject WebApplicationContext into the test. The second approach does not load the Spring configuration.

While both options work, my preference is to use the second approach that doesn’t load the Spring configuration. Rather, I use Mockito to mock out all the dependencies within the controller.

EXAMPLE

Let’s assume we want to test this controller:-

@Controller
@RequestMapping(value = "/comment/{uuid}")
public class CommentController {

    @Autowired
    private RequestService requestService;

    @Autowired
    private CommentValidator validator;

    @InitBinder("commentForm")
    protected void initBinder(WebDataBinder binder) {
        binder.setValidator(validator);
    }

    @RequestMapping(method = RequestMethod.POST)
    public String saveComment(@PathVariable String uuid,
                              @Valid @ModelAttribute CommentForm commentForm,
                              BindingResult result,
                              Model model) {

        RequestComment requestComment = requestService.getRequestCommentByUUID(uuid);

        if (requestComment == null) {
            return "redirect:/dashboard";
        }

        if (result.hasErrors()) {
            return "comment";
        }

        return "ok";
    }
}

SETTING UP TEST FILE

To test /comment/{uuid} POST, we need three tests:-

requestComment is null, which returns redirect:/dashboard view.
Form validation contains error, which returns comment view.
Everything works fine, which returns ok view.

The test file looks something like this:-

public class CommentControllerTest {

    @Mock
    private RequestService requestService;

    @Mock
    private CommentValidator validator;

    @InjectMocks
    private CommentController commentController;

    private MockMvc mockMvc;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);

        mockMvc = MockMvcBuilders.standaloneSetup(commentController).build();

        when(validator.supports(any(Class.class))).thenReturn(true);
    }

    @Test
    public void testSaveComment_RequestCommentNotFound() throws Exception {
		...
    }

    @Test
    public void testSaveComment_FormError() throws Exception {
		...
    }

    @Test
    public void testSaveComment_NoError() throws Exception {
		...
    }
}

Because the controller has two dependencies ( RequestService and CommentValidator ) injected into it through Spring autowiring, we are going to create these two mocks and inject them into the controller by annotating them with Mockito’s @Mock and @InjectMocks accordingly.

In setup(...) method, the first line initializes objects annotated with @Mock. The second line initializes MockMvc without loading Spring configuration because we want the flexibility to mock the dependencies out using Mockito. The third line instructs the validator to return true when validator.support(...) is invoked. If the third line is left out, you will get this exception when binder.setValidator(validator) in the controller.initBinder(...) is invoked:-

org.springframework.web.util.NestedServletException: Request processing failed;
nested exception is java.lang.IllegalStateException: Invalid target for Validator
[validator]: com.choonchernlim.epicapp.form.CommentForm@1a80b973

Finally, we have three stubs to test the conditions defined earlier.

TEST CASE 1: `requestComment` is null

public class CommentControllerTest {

	...

    @Test
    public void testSaveComment_RequestCommentNotFound() throws Exception {
        when(requestService.getRequestCommentByUUID("123")).thenReturn(null);

        mockMvc.perform(post("/comment/{uuid}", "123"))
                .andExpect(status().isMovedTemporarily())
                .andExpect(view().name("redirect:/dashboard"));
    }
}

The first test is rather easy. All we need to do is to instruct requestService.getRequestCommentByUUID(...) to return null when it is invoked.

TEST CASE 2: Form validation contains error

public class CommentControllerTest {

	...

    @Test
    public void testSaveComment_FormError() throws Exception {
        when(requestService.getRequestCommentByUUID("123")).thenReturn(new RequestComment());

        doAnswer(new Answer() {
            @Override
            public Object answer(InvocationOnMock invocationOnMock) throws Throwable {
                Errors errors = (Errors) invocationOnMock.getArguments()[1];
                errors.reject("forcing some error");
                return null;
            }
        }).when(validator).validate(anyObject(), any(Errors.class));

        mockMvc.perform(post("/comment/{uuid}", "123"))
                .andExpect(status().isOk())
                .andExpect(view().name("comment"));
    }
}

The second test is a little complicated. We need to instruct requestService.getRequestCommentByUUID(...) to return a RequestComment object. Then, we use Mockito’s doAnswer(...) to set a dummy error value to Errors object, which is the second argument of validator.validate(...). Setting this value will cause result.hasErrors() to evaluate to true.

TEST CASE 3: Everything works fine

public class CommentControllerTest {

	...

    @Test
    public void testSaveComment_NoError() throws Exception {
        when(requestService.getRequestCommentByUUID("123")).thenReturn(new RequestComment());

        mockMvc.perform(post("/comment/{uuid}", "123"))
                .andExpect(status().isOk())
                .andExpect(view().name("ok"));
    }
}

The third test is rather easy too. We need to instruct requestService.getRequestCommentByUUID(...) to return a RequestComment object… and that’s it.

CONCLUSION

See… it’s not really that hard. The combination of Mockito and Spring Test Framework 3.2 provides us a great flexibility to test our Spring MVC controllers. Granted, we should already have our unit tests for the two dependencies ( RequestService and CommentValidator ) already. So, it is safe to alter the behavior of these dependencies using Mockito to test every possible path in the controller.

The post MockMvc + Mockito = Epic Tests appeared first on My Shitty Code.

How to Unit Test Spring MVC Controller

Shitty Author — Wed, 23 Oct 2013 20:23:01 +0000

SCENARIO

Let’s assume we have the following controller that needs to be tested:-

@Controller
@RequestMapping(value = "/person")
public class PersonController {

    private PersonService personService;

    @Autowired
    public PersonController(PersonService personService) {
        this.personService = personService;
    }

    @RequestMapping(value = "/{id}", method = RequestMethod.GET)
    public String getPerson(@PathVariable Long id, Model model) {
        model.addAttribute("personData", personService.getPerson(id));
        return "personPage";
    }
}

SOLUTION 1: “Works but It Won’t Get You the Promotion”

This working solution relies on:-

JUnit – General unit test framework.
Mockito – To mock PersonService.

public class PersonControllerTest {

    @Test
    public void testGetPerson() {

        PersonService personService = mock(PersonService.class);

        when(personService.getPerson(1L)).thenReturn(new Person(1L, "Chuck"));

        PersonController controller = new PersonController(personService);

        Model model = new ExtendedModelMap();

        String view = controller.getPerson(1L, model);

        assertEquals("View name", "personPage", view);

        Person actualPerson = (Person) model.asMap().get("personData");

        assertEquals("matching ID", Long.valueOf(1), actualPerson.getId());
        assertEquals("matching Name", "Chuck", actualPerson.getName());
    }
}

While this solution works, but it has a few problems. This test case strictly tests the actual controller API, but it completely disregards the URI and request method (GET, POST, PUT, DELETE, etc). For instance:-

What if the URI has a typo ( /persn/1 ) or it is not properly constructed ( /person/donkey-kong )?
What if the request method should be a POST but we accidentally used a GET?

SOLUTION 2: “A Mind Blowing Solution that Still Won’t Get You the Promotion but You Feel So Invincible That You Feel Compelled to Flip a Table Over”

This better solution relies on:-

JUnit – General unit test framework.
Mockito – To mock PersonService.
Spring MVC Test Framework – To properly test the controller.
Hamcrest – To clean way to assert the actual result is correct.

@RunWith(SpringJUnit4ClassRunner.class)
// This XML configuration basically enable component scanning.
// You could have used @Configuration and @ComponentScan to do the same thing.
@ContextConfiguration({"classpath*:spring-test.xml"})
public class PersonControllerTest {

    @Mock
    private PersonService personService;

    @InjectMocks
    private PersonController personController;

    private MockMvc mockMvc;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);
        mockMvc = MockMvcBuilders.standaloneSetup(personController).build();
    }

    @Test
    public void testGetPerson() throws Exception {
        when(personService.getPerson(1L)).thenReturn(new Person(1L, "Chuck"));

        mockMvc.perform(get("/person/{id}", 1L))
                .andExpect(status().isOk())
                .andExpect(view().name("personPage"))
                .andExpect(model().attribute("personData",
                                             allOf(hasProperty("id", is(1L)),
                                                   hasProperty("name", is("Chuck")))));
    }
}

Basically object that is annotated with @Mock will get injected into object that is annotated with InjectMocks. Then, we rely on Spring MVC Test Framework’s MockMvc to test our controller in a very clean and detailed fashion.

Okay, you may flip a table over now…

By the way…

You need at least Spring 3.2 to use MockMvc.


	org.springframework
	spring-test
	3.2.4.RELEASE
	test

If you are using an older Mockito version, you will get this error:-

org.mockito.exceptions.base.MockitoException: Field 'personController' annotated with @InjectMocks is null.
Please make sure the instance is created *before* MockitoAnnotations.initMocks();
Example of correct usage:
   class SomeTest {
      @InjectMocks private Foo foo = new Foo();

      @Before public void setUp() {
         MockitoAnnotations.initMock(this);

Upgrading Mockito to the latest version will fix this error:-


	org.mockito
	mockito-core
	1.9.5
	test

The post How to Unit Test Spring MVC Controller appeared first on My Shitty Code.