47

I have an interface Foo with method int Foo.bar(int) that I want to mock with Mockito. I want the mocked method to return 99 if I pass in 1, but all other values will throw an exception. Can I do this?

final Foo foo = mock(Foo.class);
when(foo.bar(1)).thenReturn(99);
when(foo.bar(anyInt())).thenThrow(new IllegalArgumentException());

In other words, will the 1 take precedence over anyInt()? I wouldn't want it throwing an exception for 1. The docs say that for multiple definitions the last definition is more important, but I couldn't tell if that meant for identical arguments or not. If it applies here, would I need to define the wildcard anyInt() first? Or do the two even have any relation, as one of them is a matcher and the other is just a value?

Garret Wilson
  • 18,219
  • 30
  • 144
  • 272
  • 1
    This is a great question, and I can find nothing in either documentation or blogs about how to achieve what you want (+1). – Tim Biegeleisen Dec 09 '15 at 05:18
  • Maybe [this question](http://stackoverflow.com/questions/26067096/how-to-write-a-matcher-that-is-not-equal-to-something/26075910#26075910) could help you altough you can see the different choices in Jeff answer (+1) – troig Dec 09 '15 at 08:30

1 Answers1

66

You have two options: Matching "any value but one", and overriding stubbing. (I suppose you could also use an Answer for complex custom behavior, but that's overkill for situations like this one.)

Stubbing any value except a given value

Mockito's AdditionalMatchers class offers a number of useful matchers, including operators such as not. This would allow you to set behavior for all values except for a specific value (or expression).

when(foo.bar(1)).thenReturn(99);
when(foo.bar(not(eq(1)))).thenThrow(new IllegalArgumentException());

Be careful to note that operators must be used with matchers instead of values, possibly requiring Matchers.eq as an explicit equals matcher, due to Mockito's argument matcher stack:

/* BAD */  when(foo.bar(not(  1  ))).thenThrow(new IllegalArgumentException());
/* GOOD */ when(foo.bar(not(eq(1)))).thenThrow(new IllegalArgumentException());

Overriding stubbing

For stubbing, the last-defined matching chain wins. This allows you to set up general test fixture behavior in a @Before method and override it in individual test cases if you wish, but also implies that order matters in your stubbing calls.

when(foo.baz(anyInt())).thenReturn("A", "B");  /* or .thenReturn("A").thenReturn("B"); */
when(foo.baz(9)).thenReturn("X", "Y");

foo.baz(6); /* "A" because anyInt() is the last-defined chain */
foo.baz(7); /* "B" as the next return value of the first chain */
foo.baz(8); /* "B" as Mockito repeats the final chain action forever */

foo.baz(9); /* "X" because the second chain matches for the value 9 */
foo.baz(9); /* "Y" forever because the second chain action still matches */

Consequently, you should never see the two stubs in the order listed in the question, because if a general match immediately follows a specific match then the specific match will never be used (and may as well be deleted).

Beware that you'll sometimes need to change syntax to doAnswer when overriding spies or dangerous stubbed behavior. Mockito knows not to count calls to when for verification or for advancing along thenVerb chains, but exceptions could still cause your test to fail.

/* BAD: the call to foo.bar(1) will throw before Mockito has a chance to stub it! */
when(foo.bar(anyInt())).thenThrow(new IllegalArgumentException());
when(foo.bar(1)).thenReturn(99);

/* GOOD: Mockito has a chance to deactivate behavior during stubbing. */
when(foo.bar(anyInt())).thenThrow(new IllegalArgumentException());
doReturn(99).when(foo).bar(1);
Community
  • 1
  • 1
Jeff Bowman
  • 90,959
  • 16
  • 217
  • 251
  • Jeff Bowman said: "if a general match immediately follows a specific match then the specific match will never be used...". Did you mean "if a general match **is immediately followed by** a specific match..."? – Garret Wilson Aug 08 '16 at 16:32
  • @Garret: No, I meant it as it is. The most-recently-defined matching chain wins, so if you make a specific match and then a more-general match **follows it** as in the question, then the general match will be the most recent matching chain and the specific behavior will be effectively deleted, which is not the behavior it sounds like you wanted. – Jeff Bowman Aug 08 '16 at 19:23
  • Gotcha. It makes sense today, but yesterday for some reason my mind was parsing the sentence to mean the opposite. Don't know why. Thanks for the response. – Garret Wilson Aug 09 '16 at 16:37