How to use nullPassedWhenCreatingInOrder method of org.mockito.internal.exceptions.Reporter class

You're misunderstanding what a mock is. When you're doing

MyClass myClass = Mockito.mock(MyClass.class);
// ...
assertNull(myClass.methodToTest(myObject));

You're not actually invoking methodToTest on your real object. You're invoking methodToTest on the mock, which by default, does nothing and return null, unless it was stubbed. Quoting from Mockito docs:

By default, for all methods that return value, mock returns null, an empty collection or appropriate primitive/primitive wrapper value (e.g: 0, false, ... for int/Integer, boolean/Boolean, ...).

This explains your subsequent error: the method was really not invoked on the mock.

It seems what you want here is a spy instead:

You can create spies of real objects. When you use the spy then the real methods are called (unless a method was stubbed).

A note of warning though: since it is the real methods that are getting called, you should not use Mockito.when but prefer Mockito.doReturn(...).when, otherwise the method will be called once for real. If you consider the expression:

Mockito.when(myClass.methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class))).thenReturn(Collections.<X, Y> emptyMap());
             ^-----------------------------------^
                 this will be invoked by Java

the argument of the method when must be evaluated, but this means the method methodUsedInMethodBeingTested will be invoked. And since we have a spy, it is the real method that will be invoked. So, instead, use:

MyClass spy = Mockito.spy(new MyClass());
Mockito.doReturn(Collections.<X, Y> emptyMap()).when(spy).methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class));
assertNull(spy.methodToTest(myObject));
Mockito.verify(spy).methodUsedInMethodBeingTested(Matchers.any(MyTypeParam.class));

The documentation covers this explicitly. You want to call verifyNoMoreInteractions, either after calling verify (as per the docs) or

verify(execution).getLastQty();
verify(execution).getLastPrice();
verifyNoMoreInteractions(execution);

or using ignoreStubs:

verifyNoMoreInteractions(ignoreStubs(execution));

To directly answer your question, yes, you can mock some methods without mocking others. This is called a partial mock. See the Mockito documentation on partial mocks for more information.

For your example, you can do something like the following, in your test:

Stock stock = mock(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
when(stock.getValue()).thenCallRealMethod();  // Real implementation

In that case, each method implementation is mocked, unless specify thenCallRealMethod() in the when(..) clause.

There is also a possibility the other way around with spy instead of mock:

Stock stock = spy(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
// All other method call will use the real implementations

In that case, all method implementation are the real one, except if you have defined a mocked behaviour with when(..).

There is one important pitfall when you use when(Object) with spy like in the previous example. The real method will be called (because stock.getPrice() is evaluated before when(..) at runtime). This can be a problem if your method contains logic that should not be called. You can write the previous example like this:

Stock stock = spy(Stock.class);
doReturn(100.00).when(stock).getPrice();    // Mock implementation
doReturn(200).when(stock).getQuantity();    // Mock implementation
// All other method call will use the real implementations

Another possibility may be to use org.mockito.Mockito.CALLS_REAL_METHODS, such as:

Stock MOCK_STOCK = Mockito.mock( Stock.class, CALLS_REAL_METHODS );

This delegates unstubbed calls to real implementations.

However, with your example, I believe it will still fail, since the implementation of getValue() relies on quantity and price, rather than getQuantity() and getPrice(), which is what you've mocked.

Another possibility is to avoid mocks altogether:

@Test
public void getValueTest() {
    Stock stock = new Stock(100.00, 200);
    double value = stock.getValue();
    assertEquals("Stock value not correct", 100.00*200, value, .00001);
}

From the docs:

Sometimes we need to stub with different return value/exception for the same method call. Typical use case could be mocking iterators. Original version of Mockito did not have this feature to promote simple mocking. For example, instead of iterators one could use Iterable or simply collections. Those offer natural ways of stubbing (e.g. using real collections). In rare scenarios stubbing consecutive calls could be useful, though:

when(mock.someMethod("some arg"))
   .thenThrow(new RuntimeException())
  .thenReturn("foo");

//First call: throws runtime exception:
mock.someMethod("some arg");

//Second call: prints "foo"
System.out.println(mock.someMethod("some arg"));

So in your case, you'd want:

when(myMock.doTheCall())
   .thenReturn("You failed")
   .thenReturn("Success");

Have you installed the Spek plugin for IntelliJ?

Just search for spek in the IntelliJ plugin settings.

Code that instantiates objects using new directly makes testing difficult. By using the Factory pattern you move the creation of the object outside of the code to be tested. This gives you a place to inject a mock object and/or mock factory.

Note that your choice of MyTest as the class to be tested is a bit unfortunate as the name implies that it is the test itself. I'll change it to MyClass. Also, creating the object in the constructor could easily be replaced by passing in an instance of A so I'll move the creation to a method that would be called later.

public interface AFactory
{
    public A create(int x, int y);
}

public class MyClass
{
    private final AFactory aFactory;

    public MyClass(AFactory aFactory) {
        this.aFactory = aFactory;
    }

    public void doSomething() {
        A a = aFactory.create(100, 101);
        // do something with the A ...
    }
}

Now you can pass in a mock factory in the test that will create a mock A or an A of your choosing. Let's use Mockito to create the mock factory.

public class MyClassTest
{
    @Test
    public void doSomething() {
        A a = mock(A.class);
        // set expectations for A ...
        AFactory aFactory = mock(AFactory.class);
        when(aFactory.create(100, 101)).thenReturn(a);
        MyClass fixture = new MyClass(aFactory);
        fixture.doSomething();
        // make assertions ...
    }
}

The reason is that the spring configuration for the test having the @MockBean is different from the rest of the tests, so the spring framework cannot cache previously used context and needs to load it again. Here you can find a more detailed explanation: https://github.com/spring-projects/spring-boot/issues/10015

As you said, if you move the mock bean to the parent class the context doesn't get reloaded, which makes sense as the bean configuration remains the same.

A possible workaround is defining your mock bean as a simple mock and injecting it manually where is required.

For instance, UserController has a dependency on Foo:

public class UserControllerTest extends BaseITCase {

    private Foo foo = Mockito.mock(Foo.class);

    @Autowired
    private UserController userController;

    @Before
    public void setUp() {
        super.setup();

        this.userController.setFoo(foo);
    }
}

@Component
public class UserController {

    private Foo foo;

    @Autowired
    public void setFoo(final Foo foo) {
        this.foo = foo;
    }
}

Hope this helps.

use

MockitoAnnotations.openMocks(this);

A good technique for getting rid of static calls on 3rd party API is hiding the static call behind an interface.

Let's say you make this interface :

interface IPDOFacade {

    IPDO getContextPDO();
}

and have a default implementation that simply calls the static method on the 3rd party API :

class IPDOFacadeImpl implements IPDOFacade {

    @Override
    public IPDO getContextPDO() {
        return Util.getContextPDO();
    }
}

Then it is simply a matter of injecting a dependency on the interface into MyClass and using the interface, rather than the 3rd party API directly :

public class MyClass {

    private final IPDOFacade ipdoFacade;

    public MyClass(IPDOFacade ipdoFacade) {
        this.ipdoFacade = ipdoFacade;
    }

    private IPDO getIPDO() {
        return ipdoFacade.getContextPDO();
    }

    public String handleIn(Object input) throws Throwable
    {
        String result = "";
        IPDO pdo = getIPDO();

        someImportantBusinessLogic(pdo);

        return result;
    }
    
    ...

}

In your unit test, you can then easily mock your own interface, stub it any way you like and inject it into the unit under test.

This

• avoids the need to make private methods package private.
• makes your tests more readable by avoiding partial mocking.
• applies inversion of control.
• decouples your application from a specific 3rd party library.