In class, we have started to look at mocking and how to implement this technique in our unit testing. I was pretty confused about how mocking worked, so I wanted to do more research on it this week. This link has simple explanations of the premise of mocking, as well as other short, yet effective, examples of mocking: https://javacodehouse.com/blog/mockito-tutorial/ .
So what is mocking? In unit testing, we evaluate the functions of different classes and methods within those classes. These methods depend on outside classes, or dependencies, in order to function properly.
But what if the code for those other classes isn’t completed yet? Or, what if there are errors lodged in our dependencies, causing our methods being tested to fail? We still want to ensure that our methods are working properly, without depending on other classes’ behavior.
Mocking can be implemented here. Mocking simulates these dependencies to keep our tested methods independent. As shown in the picture below, the mocks eliminate the need for other classes or dependencies coming from outside of the methods that we want tested.
There are several mocking frameworks out there, including Mockito and PowerMock. We used Mockito in class, so I will be going over that framework more in this post, even though both have the same function.
First, we need to initialize our mocks. Our class did this differently than what is explained in this article, which shows the annotation @Mock for the classes that we want mocked at the beginning of the unit testing, and then using the following statement in our setup: MockitoAnnotations.initMocks(this).
Now that this is set up, we can start performing our testing! Two functions that we used extensively are the “when” “then” pattern, and the “verify” method. The “when” part of the “when-then” pattern passes in a function that requires use of the mocked class and returns a “stub” of the type to be returned from our mocked method. “Then” shows what is expected to be returned after completing our mocked method. “Then” methods can include “thenReturn(returnValue)” or “thenThrow(exceptions)” for different outcomes from the mocked method.
The “verify” method comes in handy when testing void methods. Because we aren’t returning anything, “verify” lets us examine, for example, if the void method is only being called once, that the correct method is being called, or that other void methods are being called instead of the one we want.
Reading this article was really eye-opening into the many different ways that mocking and Mockito can come into play, and I hope to work more hands-on with it in the future to learn even more about how it works.