Setting Up Mockito

7:02 with Unsubscribed User

In order to preserve the "unit" in unit testing, often we need to mock, or fake, the functionality of certain objects. There are several popular libraries out there to choose from. We'll be using Mockito, so this video shows you how to get started with Mockito.

Teacher's Notes
Video Transcript
Downloads

Sync Your Code to the Start of this Video

git checkout -f v4

Using Git with this Workshop

See the README on Github for information on how to use Git with this repo to follow along with this workshop.

Alternate Approaches to Setting Up Mockito

Without the MockitoJUnitRunner

If you want to run your unit tests without the MockitoJUnitRunner, you can delete the @RunWith annotation from the class. Then, you'll need to tell Mockito to initialize the mocks according to your @InjectMocks and @Mock annotations:

public class FavoriteControllerTest {
  private MockMvc mockMvc;

  @InjectMocks
  private FavoriteController controller;

  @Mock
  private FavoriteService service;

  @Before
  public void setup() {
    MockitoAnnotations.initMocks(this); // Initialize according to annotations
    mockMvc = MockMvcBuilders.standaloneSetup(controller).build();
  }
}

Construct Mocks Yourself

If you'd like to construct and initialize the mocks yourself, you have options. Here is one way to do this:

public class FavoriteControllerTest {
  private MockMvc mockMvc;
  private FavoriteController controller;
  private FavoriteService service;

  @Before
  public void setup() {
    // Construct the service mock
    service = Mockito.mock(FavoriteService.class);
    controller = new FavoriteController(service,null,null);
    mockMvc = MockMvcBuilders.standaloneSetup(controller).build();
  }
}

Of course, this will require a constructor in the FavoriteController class. Because we don't want to break Spring's dependency injection, you can mark this constructor as @Autowired, which means that any parameter values will be injected according to available beans. This is a nice, test-friendly alternative to autowired fields, which require reflection for DI. Here's the relevant part of the FavoriteController class:

@Controller
public class FavoriteController {
  // @Autowired annotations removed from fields

  private FavoriteService favoriteService;
  private PlacesService placesService;
  private WeatherService weatherService;

  @Autowired // Added for Spring DI
  public FavoriteController(
        FavoriteService favoriteService,
        PlacesService placesService,
        WeatherService weatherService) {
     this.favoriteService = favoriteService;
     this.placesService = placesService;
     this.weatherService = weatherService;
  }
}

Overview of Mocking

Wikipedia has a nice explanation of what mock objects are: https://en.wikipedia.org/wiki/Mock_object

Here is a nice supplement to our mocking work, still within the context of Spring: https://dzone.com/articles/mocking-in-unit-tests

Popular Mocking Libraries

0:00
On to the topic of faking, I mean marking, well same thing really.
0:05
Let's consider what it means to unit test the favorites controller.
0:08
I will open that now, favorite control.
0:12
Let's hone in on testing the index method and that's this first one right here.
0:17
As you can see,
0:18
when this method is executed the service's FindAll method is called.
0:23
If we want these unit tests to focus entirely on the favorite controller
0:27
then testing this method should not rely on a working implementation of
0:31
the favorite service.
0:33
After all we'll write unit tests for that service.
0:37
What we do in this case is mock this favorite service.
0:41
That is, we create a fake implementation of a favorite service and tell that fake
0:46
object what to do when its method, like this FindAll method, is called.
0:51
In the case of testing the index method, we'll mock the service and
0:54
configure what we want the mock object to return when its FindAll method is called.
1:00
Before we do that though let's go get the class set up to use a mocking library
1:03
called mockito.
1:05
Now to create the favorite controller test what you can do is use Ctrl or
1:09
Cmd+Shift+T, to create a new test if one doesn't exist already.
1:14
So I'll just accept the default here and yes I will add it to my get repository.
1:22
Cool, and what you'll see is that IntelliJ will automatically do a static import of
1:25
all those junit assertions whether you use them or not.
1:30
I'll leave that in there for now.
1:34
Just like the weather controller test, we'll need a field for
1:36
the MockMvc object and the controller.
1:38
So let's get those in there.
1:40
So private MockMvc right there.
1:44
MockMvc and let's get a field in there for the favorite controller.
1:49
FavoriteController and I'll name this one simply controller.
1:54
We'll be initializing this in the same way as we did before.
2:00
So let's use public void setup here.
2:03
And let's initialize that mockMvc object using that stand alone set up.
2:08
Remember that comes from the MockMvcBuilders class,
2:12
MockMvcBuilders.standaloneSetup passing it the controller and building it.
2:18
Cool.
2:20
Notice that in this case I didn't initialize the FavoriteController at all,
2:24
so how is it not null?
2:26
Well, right now it will be null, but
2:28
let's have our mapping library take care of that for us.
2:32
Mockito is not the only mocking library out there,
2:36
you'll see lots of developers using EasyMock as well.
2:39
Check the teacher's notes for more info on mocking libraries.
2:42
I'll mention some mocking features as we use them and
2:44
know that each library has its own version of the features you see here.
2:49
To fully leverage the set up capabilities of Mockito we'll
2:51
say that these tests should be run by the MockitoJUnitRunner.
2:55
And to do that, I'll use the RunWith annotation.
2:58
Passing it the Mockito, let's import that there, there we go.
3:02
The mockitojunitrunner.class, cool.
3:08
This will use Mockito's JUnitRunner instead of JUnit's JUnitRunner.
3:13
The nice thing about this is that it gives us the ability to leverage some handy
3:16
annotations.
3:17
For example, the InjectMocks annotation which I will apply to the controller.
3:23
@InjectMocks.
3:26
What this does is, create an instance of a favorite controller,
3:31
using the default constructor of the controller class.
3:34
And then it will inject any field annotated with the mock annotation
3:38
into this favorite controller.
3:41
For example, we want to mock the favorite service.
3:45
So let's create one of those and
3:48
annotate it with the mock annotation private FavoriteService.
3:55
And I'll just call it service.
3:58
So, a mock object will be created by Mockito and stored into the service field,
4:03
and injected into the favorite service field of the favorite controller here.
4:09
Check out the teacher's notes for alternate approaches for
4:11
setting up these mocks and getting them into the appropriate classes,
4:16
that is injecting them.
4:19
Okay.
4:19
Let's now create our test methods and
4:21
look at the general steps we'll need to take in each method.
4:23
First let's test that the favorite controller's index method
4:26
actually includes a list of favorites in the model.
4:29
So let me go down here and create a new test method and we'll call it public void.
4:36
The index method should include the favorites in the model.
4:45
That that throws an exception.
4:48
So essentially what we'll be doing here is we'll be making a request to the mockMvc
4:52
object that will lead to a call to the FavoriteController's index method.
4:57
And what this test method will do is ensure that the proper
5:01
favorite objects were added to the model before the view is rendered.
5:05
Okay, let's stub out another test method.
5:08
So we'll make sure adding a favorite redirects to the new favorite's
5:12
detail page.
5:13
Let's write a test for that.
5:15
public void, and we'll say that the add_ method, ShouldRedirectToNewFavorite.
5:22
I'll declare it as throwing an exception again, as we do with all test methods.
5:28
And finally, how about we test that when trying to access a detail page for
5:32
a favorite that doesn't exist, we get the proper error page.
5:35
So, let's write a test, That ensures
5:41
that the detail_ShouldErrorOnNotFound.
5:50
And though each one of these test methods tests a different kind of functionality,
5:55
the general idea will be the same, that is, we will first arrange the mock
6:00
behavior, And then,
6:05
we'll act, that is, we'll perform the MVC request and we'll assert the result.
6:14
So this is going to be the same for all those methods.
6:18
I'm going to paste those comments in each one of those test methods.
6:22
And you'll notice that the general layout of our test with mocks still
6:24
follows the rule of AAA.
6:26
That is arrange, act, and assert.
6:30
Arranging involves setting up our system under test often abbreviated as UT which
6:36
for us includes setting up the mockMvc object as well as our controller and
6:40
mock service.
6:42
Acting involves performing the actual MVC request and asserting will for us involve
6:48
calling that and expect method that you saw in the weather controller test.
6:54
In the next video we'll fill in all the code for each one of these test methods
6:57
and you'll begin to see some pretty cool stuff that we can do with Mockito.

You need to sign up for Treehouse in order to download course files.

Unit Testing a Spring Application