906

How to verify that a method is not called on an object's dependency?

For example:

public interface Dependency {
    void someMethod();
}

public class Foo {
    public bar(final Dependency d) {
        ...
    }
}

With the Foo test:

public class FooTest {
    @Test
    public void dependencyIsNotCalled() {
        final Foo foo = new Foo(...);
        final Dependency dependency = mock(Dependency.class);
        foo.bar(dependency);
        **// verify here that someMethod was not called??**
    }
}
javadev
  • 688
  • 2
  • 6
  • 17
beluchin
  • 12,047
  • 4
  • 24
  • 35

7 Answers7

1497

Even more meaningful :

import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;

// ...

verify(dependency, never()).someMethod();

The documentation of this feature is there §4 "Verifying exact number of invocations / at least x / never", and the never javadoc is here.

Michael Xin Sun
  • 1,174
  • 1
  • 10
  • 12
bric3
  • 40,072
  • 9
  • 91
  • 111
  • 180
    Using `never` is the best and most specific way, but if you need to check an entire mock object, also consider `verifyZeroInteractions(mockObject)` or `verifyNoMoreInteractions(mockObject)`. – Jeff Bowman Oct 12 '12 at 19:18
  • what to do if someMethod is private?? – Sumit Kumar Saha Aug 01 '19 at 13:43
  • 1
    Then you can not mock it in the first place (with Mockito) ;) PowerMock allows to that but it's more complex to set up. Or if you have ownership of the code, you relax the visibility to package. – bric3 Aug 01 '19 at 14:26
  • 24
    Since 3.0.1 `verifyZeroInteractions` has been deprecated. `verifyNoInteractions ` is the suggested a alternative. Mockito version at the time of this comment is 3.3.3 – VKB Apr 29 '20 at 17:51
  • @bric3 generally private methods shouldn't be tested, but if you do want to test them, that can be a good sign that the method should be more visible, potentially even extracted to a separate class altogether. – Hubert Grzeskowiak Apr 27 '23 at 05:02
  • @HubertGrzeskowiak this answer is not about private methods ;) But about private methods, that's why we never tried to support private method mocking in mockito. – bric3 Apr 28 '23 at 08:28
173

Use the second argument on the Mockito.verify method, as in:

Mockito.verify(dependency, Mockito.times(0)).someMethod()
Naman
  • 27,789
  • 26
  • 218
  • 353
beluchin
  • 12,047
  • 4
  • 24
  • 35
  • 14
    public static VerificationMode never() { return times(0); } – gbero Apr 25 '17 at 12:20
  • 12
    `never()` is not significantly more readable than `times(0)`. But the existence of `never` does increase cognitive load and makes the mockito system harder to understand and remember how to use. So really mockito shouldn't have included `never` in their API, its not worth the mental cost. – B T Jan 14 '19 at 21:56
  • 1
    Question: does this form verify that `someMethod` was called 0 times, or does it only verify that `someMethod` was never called with zero arguments? – B T Jan 14 '19 at 21:57
  • 1
    @B T - I would imagine it verifies the `someMethod` with zero arguments was called zero times- not verified. – beluchin Jan 15 '19 at 09:25
  • Same works for jmockit btw, times=0; – Fakrudeen Nov 12 '21 at 18:47
40

First of all: you should always import mockito static, this way the code will be much more readable (and intuitive):

import static org.mockito.Mockito.*;

There are actually many ways to achieve this, however it's (arguably) cleaner to use the

verify(yourMock, times(0)).someMethod();

method all over your tests, when on other Tests you use it to assert a certain amount of executions like this:

verify(yourMock, times(5)).someMethod();

Alternatives are:

verify(yourMock, never()).someMethod();

Alternatively - when you really want to make sure a certain mocked Object is actually NOT called at all - you can use:

verifyZeroInteractions(yourMock)

Please Note: verifyZeroInteractions(Object... mocks) is Deprecated. Since Version 3.0.1. The now recommended method is:

verifyNoInteractions(yourMock)
fl0w
  • 3,593
  • 30
  • 34
31

As a more general pattern to follow, I tend to use an @After block in the test:

@After
public void after() {
    verifyNoMoreInteractions(<your mock1>, <your mock2>...);
}

Then the test is free to verify only what should be called.

Also, I found that I often forgot to check for "no interactions", only to later discover that things were being called that shouldn't have been.

So I find this pattern useful for catching all unexpected calls that haven't specifically been verified.

David Lavender
  • 8,021
  • 3
  • 35
  • 55
  • 10
    The Mockito documentation states that this pattern should not be abused -- "A word of warning: Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method. verifyNoMoreInteractions() is not recommended to use in every test method. verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant. Abusing it leads to overspecified, less maintainable tests." See [here](http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#8) – Chadi Mar 04 '16 at 13:31
  • 4
    "Use it only when it's relevant". I feel that it is always relevant. I don't see that pattern as abuse: like I said, it finds "things were being called that shouldn't have been". To me, that's a vital piece of verification: if something is calling a repository that it shouldn't be using, I want to know about it! Unless there's another way to verify that without using `verifyNoMoreInteractions`? The other answers here rely on the test writer explicitly remembering to list out these checks: that's too error prone in my book. – David Lavender May 31 '16 at 15:55
  • 2
    I saw this comment, but also felt like the reasoning was not compelling. I would love to read more about why this is not recommended. – tobinibot Nov 08 '16 at 04:02
  • 2
    @tobinibot Because the idea of unit testing is to verify a Contract. Most contracts don't typically involved how many times some other method is invoked, but rather that passing in known parameters results in a known response. By using no more interactions you're basically verifying the implementation line by line, which makes refactoring and implementation tedious. Which isn't the point of unit testing. – Andrew T Finnell Sep 21 '18 at 21:26
  • 1
    I've run into multiple times where we verify something was not called, then later change the implementation to call something else.. and the old test still passes, because the old method is still not called, but we didn't verify the new method. The pattern suggested here will help ensure your test stays relevant - if you update code without updating a test, you may have hidden issues and assume your test still covers it. I agree with @DavidLavender: "The other answers here rely on the test writer explicitly remembering to list out these checks: that's too error prone in my book." – aarowman Mar 25 '21 at 21:26
12

Both the verifyNoMoreInteractions() and verifyZeroInteractions() method internally have the same implementation as:

public static transient void verifyNoMoreInteractions(Object mocks[])
{
    MOCKITO_CORE.verifyNoMoreInteractions(mocks);
}

public static transient void verifyZeroInteractions(Object mocks[])
{
    MOCKITO_CORE.verifyNoMoreInteractions(mocks);
}

so we can use any one of them on mock object or array of mock objects to check that no methods have been called using mock objects.

byxor
  • 5,930
  • 4
  • 27
  • 44
Ujjwal
  • 2,365
  • 2
  • 11
  • 7
4

Just as a suggestion, if you want to be more aligned at syntax level with Behavior-driven development style there is BDDMockito:

You could use:

then(dependency).should(never()).someMethod();

As an equivalent replacement of:

verify(dependency, never()).someMethod();
Alex Blasco
  • 793
  • 11
  • 22
1

Couple of options to do that depending on the use case.

If you want to verify that someMethod is not invoked on dependency use below

verify(dependency, times(0)).someMethod();

or much better readable option

verify(dependency, never()).someMethod();

If you want that no interaction on specific dependency to happen, then use below.

verifyNoInteractions(dependency);

If there are multiple methods on a dependency and you want to make sure only expected method is invoked and nothing else. Then use

verify(dependency, times(1)).someMethod();
verifyNoMoreInteractions(dependency);
Sanjay Bharwani
  • 3,317
  • 34
  • 31