Unit testing with Mockito and AssertJ

A few weeks ago I wrote my very first Spring Boot application and I was quite astonished about the result. Now, I did want to complete the application by writing some tests and so I did. In my previous tutorial I wrote several integration tests, and now it’s time to write some unit tests as well.

First of, the code I will be testing is a Spring RestController I wrote a while ago, the code looks like this:

public class ItemController {
  private ItemRepository repo;

  @RequestMapping(method = RequestMethod.GET)
  public List findItems() {
    return repo.findAll();

  @RequestMapping(method = RequestMethod.POST)
  public Item addItem(@RequestBody Item item) {
    return repo.saveAndFlush(item);

  @RequestMapping(value = "/{id}", method = RequestMethod.PUT)
  public Item updateItem(@RequestBody Item updatedItem, @PathVariable Integer id) {
    Item item = repo.getOne(id);
    return repo.saveAndFlush(item);

  @RequestMapping(value = "/{id}", method = RequestMethod.DELETE)
  @ResponseStatus(value = HttpStatus.NO_CONTENT)
  public void deleteItem(@PathVariable Integer id) {

  @ExceptionHandler(value = { EmptyResultDataAccessException.class, EntityNotFoundException.class })
  public void handleNotFound() { }

Maven configuration

If you followed my previous tutorial, you can skip this section as it is mostly a recap of what I did in that tutorial.

In my previous tutorial, I already explained how to configure Maven. First of all we need the maven-surefire-plugin:


I’m using a property called ${unit-tests.skip}, though I always recommend running the unit tests…. but you never know.

Now, in this tutorial I will be using Mockito and AssertJ, if you haven’t heard of them, make sure to check them out! But obviously, we will have to add those to our classpath as well, so let’s add them as Maven dependencies, together with JUnit.


The application I’m going to write unit tests for is a Spring boot application, because the parent POM already has JUnit as a managed dependency, we don’t need to provide a version for that library.

Just like the property for skipping the unit tests before, I’m also using properties here ({assertj-version}). Obviously we have to define those as well:


If you’re using Spring Boot, then you don’t have to define a version for Mockito, since it’s already included in the dependency management of the parent POM.

Using the builder pattern

I really like writing builders for my model classes, because they make it so much easier to create new model objects. In this case I will be writing a builder for my model, the Item class.

So let’s create the ItemBuilder class inside the be.g00glen00b.builders package inside the test source folder (src/test/java). The content of this file is quite simple, I wrote a method for each setter, and a separate build() method:

package be.g00glen00b.builders;

import be.g00glen00b.model.Item;

public class ItemBuilder {
  private Item item = new Item();
  public ItemBuilder id(int id) {
    return this;
  public ItemBuilder description(String description) {
    return this;
  public ItemBuilder checked() {
    return this;
  public Item build() {
    return item;

By returning an ItemBuilder with each method, I can chain them up, for example:

new ItemBuilder().description("My item").checked().build();

Setting up JUnit with Mockito

Well, we’ve set up all code we need, so now it’s time to write a test case. Mockito provides a simple runner for JUnit, which makes it possible to automatically inject mocks inside your tested classes. This makes testing really easy. To set up a JUnit test case with Mockito, you need to add some annotations to it, for example:

public class ItemControllerTest {
  private ItemController controller;
  private ItemRepository repository;

That’s all we need to do, just add a @RunWith() annotation with the MockitoJUnitRunner and by doing so you can inject all mocked objects with @Mock and the test class (that needs injected mocks) with @InjectMocks.

This makes testing really easy, because now we have a testable object (controller) and the mocks that are injected (repository). After running each test, the mocks are reset automatically and new instances are created, so it leaves no trace behind.

Before writing our tests, I’m going to need some test models to use with our mocks. Simply add the following constants:

private static final int CHECKED_ITEM_ID = 1;
private static final Item CHECKED_ITEM = new ItemBuilder()
private static final Item UNCHECKED_ITEM = new ItemBuilder()
private static final Item NEW_ITEM = new ItemBuilder()

I will also use a Mockito captor in one of my tests, which I will set up as a field as well:

private ArgumentCaptor anyItem = ArgumentCaptor.forClass(Item.class);

Writing a test with Mockito and AssertJ

Writing tests with Mockito and AssertJ explains itself quite easily, take for example this test:

public void whenFindingItemsItShouldReturnAllItems() {
  // Given that the repository returns CHECKED_ITEM and UNCHECKED_ITEM
  given(repository.findAll()).willReturn(Arrays.asList(CHECKED_ITEM, UNCHECKED_ITEM));
  // When looking for all items
  // Then it should return the CHECKED_ITEM and UNCHECKED_ITEM 

At the first line, we’re providing some data to our mocks, so that when repository.findAll() is executed, it will return a list of both CHECKED_ITEM and UNCHECKED_ITEM.

Then the next step is the assertion. Given that our repository returns those items, it should mean that when we call controller.findItems()), it will contain only CHECKED_ITEM and UNCHECKED_ITEM.

Obviously, in real code a test will not be that easy, but still, this code makes so much sense, I could probably show it to my mother and she probably understands it as well… . Well, not entirely since she doesn’t know what controllers and repositories are, but you get the point.

But most of our tests are just that simple, for example:

public void whenAddingItemItShouldReturnTheSavedItem() {
  // Given that a NEW_ITEM is saved and flushed, a CHECKED_ITEM is returned
  // When adding a NEW_ITEM
  // Then it should return the CHECKED_ITEM

public void whenUpdatingItemItShouldReturnTheSavedItem() {
  // Given that CHECKED_ITEM is returned when one is requested with CHECKED_ITEM_ID
  // Given that a CHECKED_ITEM is saved and flushed, a CHECKED_ITEM is returned
  // When updating a CHECKED_ITEM
  assertThat(controller.updateItem(CHECKED_ITEM, CHECKED_ITEM_ID))
  // Then it should return the CHECKED_ITEM

Verifying calls

However, sometimes this is not enough. Sometimes you want to verify that a specific method has been called. For example, if we take a look at the delete REST API, we notice that the method has a void signature, meaning that we can’t simply test that something is correctly returned.

No, in this case you would like to check if the delete() function has been called on the repository. With Mockito, you can use the verify() method to verify that a specific method inside a mock has been called. For example:

public void whenDeletingAnItemItShouldUseTheRepository() {
  // Given that an item with CHECKED_ITEM_ID is removed
  // Verify that the repository is used to delete the item

The verify() method also allows you to provide specific matchers, for example:


This piece of code will verify that the delete() method has been called with any integer.

But sometimes, you have a complex object, and you want to check if a certain property is filled. Well, if you use Mockito’s ArgumentCaptor, that’s no problem either. You can simply create a captor like this:

ArgumentCaptor captor = ArgumentCaptor.forClass(Type.class);

If you look back in the code we defined earlier, you will notice that we already defined an argument captor as a field inside the test case. With the anyItem captor, we can check any Item argument, for example:

public void whenAddingItemItShouldMakeSureNoIDIsPassed() {
  // Given that a CHECKED_ITEM is added
  // Verify that when the item is saved
  // It should have an empty ID

public void whenUpdatingItemItShouldUseTheGivenID() {
  // Given that CHECKED_ITEM is returned when one is requested with CHECKED_ITEM_ID
  // Given that a CHECKED_ITEM with CHECKED_ITEM_ID is updated
  controller.updateItem(NEW_ITEM, CHECKED_ITEM_ID);
  // Verify that when the item is saved
  // It should have the given CHECKED_ITEM_ID

As you can see, with anyItem.capture() we can tell Mockito which argument we’d like to capture, and with anyItem.getValue() we can retrieve the actual object that was passed and use it for further assertions with AssertJ.

So, that’s about it for this tutorial. In the next part of this series I will talk about executing JavaScript tests using Maven.

Achievement: Wrote unit tests using Mockito and AssertJ

Seeing this means you managed to read through this (short) tutorial about unit testing your code using Mockito and AssertJ. If you’re interested in the full code example, you can find it on GitHub. If you want to try out the code yourself, you can download an archive from GitHub.

Tagged , , , .


Consultant at Cronos and Tech lead at Aquafin. Usually you can find me trying out new libraries and technologies. Loves both Java and JavaScript.