org.mockito.exceptions.misusing

Class PotentialStubbingProblem

java.lang.Object

java.lang.Throwable

java.lang.Exception

java.lang.RuntimeException

org.mockito.exceptions.base.MockitoException

org.mockito.exceptions.misusing.PotentialStubbingProblem

All Implemented Interfaces:

Serializable

public class PotentialStubbingProblem
extends MockitoException

Strict stubbing is a new feature introduced in Mockito 2.3. Detecting potential stubbing problems is intended to help writing and debugging tests. The org.mockito.exceptions.misusing.PotentialStubbingProblem exception is thrown when a mock method is stubbed with argument X in test but then invoked with argument Y in code. Example:

 //test method:
 given(mock.getSomething(100)).willReturn(something);

 //code under test:
 Something something = mock.getSomething(50); // <-- stubbing argument mismatch
 

The stubbing argument mismatch typically happens in following use cases:

1. Mistake or typo in the test code, the argument(s) used when declaring stubbings is unintentionally different
2. Mistake or typo in the code under test, the argument(s) used in the code under test is unintentionally different
3. Intentional use of stubbed method with different argument, either in the test (more stubbing) or in code under test

This exception is very useful for 95% of the cases (use cases 1 and 2). However, it can give false negative signal for 5% of the cases (use case 3). It is a trade-off for better debuggability and productivity of the typical cases.

What to do if you fall into use case 3? You have 2 options:

1. Do you see this exception because you're stubbing the same method multiple times in the test? In that case, please use BDDMockito.willReturn(Object) or Mockito.doReturn(Object) family of methods for stubbing. Good looking stubbing via Mockito.when(Object) has its drawbacks: the framework cannot distinguish between actual invocation on mock and the stubbing attempt in the test. Hence the need to use BDDMockito.willReturn(Object) or Mockito.doReturn(Object) for certain edge cases.
2. In Mockito 2.x, simply don't use MockitoRule.strictness(Strictness) with Strictness.STRICT_STUBS for that test. You will lose stubbing strictness but at least you can complete the test.

We are very eager to hear feedback about "strict stubbing" feature, let us know by commenting on GitHub issue 769. Strict stubbing is an attempt to improve testability and productivity with Mocktio. Tell us what you think!

Since:

2.3.0

See Also:

Serialized Form

Constructor Summary

Constructors

Constructor and Description
PotentialStubbingProblem(String message)

Method Summary

Methods inherited from class org.mockito.exceptions.base.MockitoException

getUnfilteredStackTrace

Methods inherited from class java.lang.Throwable

fillInStackTrace, getCause, getLocalizedMessage, getMessage, getStackTrace, initCause, printStackTrace, printStackTrace, printStackTrace, setStackTrace, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Detail

PotentialStubbingProblem

public PotentialStubbingProblem(String message)