Writing tests for an unknown code is either difficult or tiresome; difficult, if I decide to understand large chucks of the project before writing a lick of code; tiresome, if I chose to only understand the module that I am changing and just mock the rest of classes when unit testing. In reality, It should be a bit of both.
In the past I made lots and lots of mock objects by making classes that implement a certain interface or try to instantiate a class with lots of dependency, when really, I only care about one or two methods in the class. It's a tiresome, verbose, and just plain an ugly thing to do for writing a unit test.
Fortunately, I came across Mockito with allows you to mock and stub classes effortlessly.
Take the
Say I want to make a change to the
Before Mockito, I would need to instantiate an instance of
What is it that I really need in order to test this code? It's the logic in
This is exactly what Mockito give me! Here is an example
The key thing to notice here is the
That's it! My unit test is concise/readable, free from a bunch of setup code. I can always setup a different list of results to test against in my unit test.
It makes writing unit tests fun versus a necessary evil.
StatsManager class that has a genderCount() method.
public class StatsManager {
private JDBCTemplate template;
public long genderCount(Gender gender) { //perform some business logic ... } public void setJDBCTemplate(JDBCTemplate template) { this.template = template; } ...
}Say I want to make a change to the
genderCount() method and I need an unit test to validate my change.Before Mockito, I would need to instantiate an instance of
JDBCTemplate. It happens that JDBCTemplate needs an javax.sql.DataSource instance to work. I would then try to make a mock class of this interface, but then it turns out that javax.sql.DataSource has a dependency javax.sql.Connection so I have to mock that class and world goes round and round... but I never finishing mocking!What is it that I really need in order to test this code? It's the logic in
genderCount() that I want to test, and don't want to concern myself with all these other setup classes/interfaces. Infact, I know that queryAsList(String sql) is the only method called on the JDBCTemplate class in StatsManager.genderCount() . All I want is a certain List of results when genderCount() is called.This is exactly what Mockito give me! Here is an example
public class StatsManagerTest {
@Test
public void testGenderCount() {
StatsManager manager = new StatsManager();
JDBCTemplate template = mock(JDBCTemplate.class)
List results = new ArrayList(); //initialize list. ... when(template.queryAsList(anyString())).thenReturns(results); long maleCount = template.genderCount(Gender.MALE); //Assert a bunch of stuff ...
long femaleCount = template.genderCount(Gender.FEMALE); //Assert a bunch of stuff ...
}
}
The key thing to notice here is the
when() and thenReturns() pair. What this is doing is that when queryAsList() is called regardless of what string is passed as a parameter, return this fixed list of results.That's it! My unit test is concise/readable, free from a bunch of setup code. I can always setup a different list of results to test against in my unit test.
It makes writing unit tests fun versus a necessary evil.
