Using partial mocks generally should be considered a code smell. When writing good and clean code, you want it to be modular and follow all of the best practices, including the SOLID principles (please refer to the Introduction section of Chapter 2, Creating Mocks, for an elaborate explanation). When working with complex code, as a refactoring process, one tries to split the largest tasks into more modular ones. During that process, you may want to mock external dependencies of the system under test. You might come across a situation in which you do not want to mock the entire dependency but only a part of it while leaving the rest unstubbed. Such a mocked class is called a partial mock and creating one means that a class that you are mocking most likely does more than one thing, which is a pure violation of the single-responsibility principle.

Let's consider the example from the current chapter – the TaxService class. It has two responsibilities:

The class both computes and updates data, so all-in-all it's not responsible for a single action, but two. If we split these responsibilities into two classes, since we don't want to really call a web service, we could create a mock only for the class responsible for updating the tax data. At the end of the day, that's how we will eliminate the need for creating a partial mock.

So why would you want to create a partial mock? You definitely would not need to do it in your new code base (because you are following the SOLID principles). However, there are cases where you will want to create partial mocks: when dealing with legacy code or third-party libraries. This would be code that you can't easily change or you can't change at all.

In this recipe, we will describe how to create partial mocks, but before that, let's have another look at the concept of a test double known as stub (based on Gerard Meszaros's definitions from the xUnit patterns). Stub is an object that has predefined answers to method executions made during the test.

The process of predefining those answers is called stubbing (refer to Chapter 4, Stubbing Behavior of Mocks, and Chapter 5, Stubbing Behavior of Spies, for more details), and you have already seen it being used with the following syntax throughout the book (an example for stubbing a method that returns a value using first the BDDMockito and then the Mockito syntax):

BDDMockito.given(...).willReturn(...)
Mockito.when(...).thenReturn(...)

public class TaxFactorProcessor {

    public static final double INVALID_TAX_FACTOR = -1;

    private final TaxService taxService;

    public TaxFactorProcessor(TaxService taxService) {
        this.taxService = taxService;
    }

    public double processTaxFactorFor(Person person) {
        try {
            double taxFactor = taxService.calculateTaxFactorFor(person);
            taxService.updateTaxData(taxFactor, person);
            return taxFactor;
        } catch (Exception e) {
            System.err.printf("Exception [%s] occurred while trying to calculate tax factor for person [%s]%n", e, person.getName());
            return INVALID_TAX_FACTOR;
        }
    }

}

@RunWith(MockitoJUnitRunner.class)
public class TaxFactorProcessorTest {

    @Mock TaxService taxService;

    @InjectMocks TaxFactorProcessor systemUnderTest;

    @Test
    public void should_return_default_tax_factor_for_person_from_undefined_country() {
        // given
        given(taxService.calculateTaxFactorFor(any(Person.class))).willCallRealMethod();

        // when
        double taxFactor = systemUnderTest.processTaxFactorFor(new Person());

        // then
        then(taxFactor).isEqualTo(TaxService.DEFAULT_TAX_FACTOR);
    }

}

@Mock(answer = Answers.CALLS_REAL_METHODS) TaxService taxService;

// given
doNothing().when(taxService).updateTaxData(anyDouble(), any(Person.class));