Mockito best practices – test behavior not implementation

Once you start testing with Mockito you might be tempted to start mocking everything that gets in your way. What is more, you may have heard that you have to mock all of the collaborators of the class and then verify whether those test doubles executed the desired methods. Of course, you can code like that, but since it is best to be a pragmatic programmer, you should ask yourself the question whether you would be interested in changing the test code each time someone changes the production code, even though the application does the same things.

It's worth going back to distinguishing stubs from mocks. Remember that, if you create a mock, it's for the sake of the verification of its method execution. If you are only interested in the behavior of your test double—if it behaves as you tell it to—then you have a stub. In the vast majority of cases, you shouldn't be interested in whether your test double has executed a particular method; you should be more interested in whether your application does what it is supposed to do. Also, remember that there are cases where it makes no sense to create a stub of an external dependency—it all depends on how you define the system under test.

It might sound a little confusing but, hopefully, the following recipe will clear things up. We will take a look at the simple example of a tax factor summing class that changes in time (whereas its tests should not change much).

Getting ready

Let's assume that we have the following tax factor calculator that calculates a sum of two tax factors:

public class TaxFactorCalculator {

    public double calculateSum(double taxFactorOne, double taxFactorTwo) {
        return taxFactorOne + taxFactorTwo;
    }

}

After some time, it turned out that we read about a library that allows you to hide the implementation details of summing and you decided to rewrite your calculator to use this library. Now your code looks as follows:

public class TaxFactorCalculator {

    private final Calculator calculator;

    public TaxFactorCalculator(Calculator calculator) {
        this.calculator = calculator;
    }

    public double calculateSum(double taxFactorOne, double taxFactorTwo) {
        return calculator.add(taxFactorOne, taxFactorTwo);
    }

}

How to do it...

Since you want to test whether your system under test works fine, you should focus on the following points:

• Start by writing a test—not with an implementation. That way, you will constantly ask yourself the question of what you want to do and only then will you think about how to do it.
• Focus on asserting the result—what you want to verify in most cases is whether your system under test works as it is supposed to. You shouldn't care much how exactly it is done.

Let's take a look at a test of the first version of the class (I'm using the BDDMockito.given(...) and AssertJ's BDDAssertions.then(...) static methods—refer to Chapter 7, Verifying Behavior with Object Matchers, for how to work with AssertJ or how to do the same with Hamcrest's assertThat(...) method):

    @Test
    public void should_calculate_sum_of_factors() {
        // given
        TaxFactorCalculator systemUnderTest =new TaxFactorCalculator();
        double taxFactorOne = 1;
        double taxFactorTwo = 2;
        double expectedSum = 3;
        
        // when
        double sumOfFactors = systemUnderTest.calculateSum(taxFactorOne, taxFactorTwo);

        // then
        then(sumOfFactors).isEqualTo(expectedSum);
    }

As you can see, we are testing a class that should add two numbers and produce a result. We are not interested in how it is done—we want to check that the result is satisfactory. Now, assuming that our implementation changed—having a good test would require only to comply to the new way that our system under test is being initialized and the rest of the code remains untouched. In other words, change TaxFactorCalculator systemUnderTest = new TaxFactorCalculator() to TaxFactorCalculator systemUnderTest = new TaxFactorCalculator(new Calculator()). Moreover, since we are checking behavior and not the implementation, we don't have to refactor the test code at all.

See also

• Martin Fowler on TDD at http://martinfowler.com/bliki/TestDrivenDevelopment.html
• Kent Beck's Test Driven Development on Amazon at http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
• Mockito's wiki page concerning how to write good tests at https://github.com/mockito/mockito/wiki/How-to-write-good-tests