Using both junit assertions and mockito verification

Question

I'm using Junit in conjunction with Mockito. I used mockito's verify method + junit assertion to do complete verification. Is this not desirable? Should we use one or the other but not both?

Answer 1

There's nothing wrong with using both.

Mockito's verify is used to assert a method was called (with the expected arguments) on the given mock.

JUnit's assertXYZ is used to assert that some result has the expected value.

Both are valid verifications, and if both are relevant, both should be used.

For example, consider the following (admittedly artificial) situation:

You have an interface that performs some mathematical calculation:

public interface ValueProducer {
    public int getValue(int val);
}

And a class that doubles any result produced by it:

public class Doubler {
    public static int doubleThatResult (ValueProducer producer, int val) {
        return 2 * producer.getValue(val);
    }
}

Testing it would require to assert two things:

1. That getValue was properly called
2. That the result is doubled

So, eg:

public class DoublerTest {

    @Test
    public void testDoubleThatResult() throws Exception {
        int value = 7; // Or any other value
        int returnMock = 13; // Or any other value

        ValueProducer producerMock = mock(ValueProducer.class);
        when(producerMock.getValue(value)).thenReturn(returnMock);

        int actual = Doubler.doubleThatResult(producerMock, value);

        verify(producerMock);
        assertEquals(26, actual);
    }
}

Answer 2

Mureinik's answer is absolutely correct—assertions and verifications are complementary, and work quite well together—but doing both for a single behavior may be redundant.

The goal is usually to express the test in the most flexible and implementation-agnostic way possible. State testing (with assertions) is often the most appropriate choice, in that sense: it doesn't matter which methods were called as long as the resulting state is correct. A Mockito verification, while possible, may introduce brittleness (where the code behaves correctly but the test is broken). Mockito itself warns of this in verify(T) 's Javadoc and the linked article by Mockito's creator Szczepan Faber .

This redundancy is certainly not the worst thing: It does test a property of the system, and may be a worthwhile endeavor in testing interactions with sensitive, legacy, third-party, or frequently-changing dependencies. If the interaction is unimportant, though, these extra verifications may come at the expense of brittleness.

Other times, confirming correct behavior means testing side-effects—for example, ensuring that someSystem.reset() was called, or testing a cache by verifying a provider was NOT called. These are perfect examples for verification, because the interaction with the external service is critical testable behavior. In some of these cases, Mockito verifications are the only way to make the correct assertions.

Many test cases are a combination of the above, so feel free to use assertions and verifications freely together; just remember that state testing is often sufficient and preferable.