How to use uncaughtException method of org.mockito.internal.stubbing.InvocationContainerImplTest class

In general, testing a class's internal function calls makes your tests far too fragile. When unit testing, you only want to see that the class as a whole is doing what it is supposed to do. You are supposed to intentionally ignore the internals.

Ignoring the internals has a lot of useful benefits. Mainly, if you change the methods -- as long as the public interface stays the same -- your tests will all still pass. Yay. This is the type of stability you want your unit tests to have. Fragile unit tests are almost worse than no unit tests. A fragile test has to be changed every time the code changes even if everything is still working. That provides you with nothing but extra work.

There are exceptions though. I would consider mocking out internal function calls in the following cases:

1) The internal call pulls data from somewhere. For example a database or large file. This is often called a 'boundary' test. We don't want to really set up a database or file to test, so instead we just sub out the function. However, if you find yourself doing this, it probably means that your class should be split into two classes because it is doing too many different things. Make yourself a dedicated database class instead.

2) The internal call does heavy processing that takes a lot of time. In that case, it might make sense to sub out the function instead of waiting. However, once again this might be a sign that you're on the wrong track. You should try to find a way to make things more partitioned so no single step takes that long.

In conclusion, I would highly recommend you do not test at the method level. A class should be a distinct unit. If the class is working everything is fine. This approach give you the testing you need to be secure and the flexibility you need to change things.

@raspacorp

Indeed, if you only test one case, someone could hardcode var = 2 and then pass your test case. But it is your job in designing tests cases to cover enough different cases to be reasonably satisfied that it is behaving appropriately.

As far as tests changing because the code has changed, this is not what you want at all. You want your tests to verify that the responses you are getting are correct for all the different types of cases. As long as the responses are correct, you want to be able to change everything without changing the tests at all.

Imagine a large system with thousands of tests verifing that everything is working right. Now imagine that you want to make a HUGE optimization change that will make things go faster, but change how everything is stored and calculated. What you want your tests to allow you to do is only change code (not tests) and have the tests continually confirm that everything is still working. This is what unit tests are for, not catching every possible line change, but rather to verify that all the calculations and behaviors are corrent.

New feature added to Mockito makes this even easier,

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

Take a look at Mockito documentation

In case when there are more than one parameters, and capturing of only single param is desired, use other ArgumentMatchers to wrap the rest of the arguments:

verify(mock).doSomething(eq(someValue), eq(someOtherValue), argument.capture());
assertEquals("John", argument.getValue().getName());

You need to first mock the class containing selectSomethingBySomething() and then record this behavior. In mockito you'll say:

SomeDao someDaoMock = mock(SomeDao.class);

willThrow(new SQLException())).given(someDaoMock).selectSomethingBySomething();

Then inject someDaoMock into your class under test and when it calls someDaoMock.selectSomethingBySomething() it'll throw previously chosen exception.

Try Adding @Spy to your InjectMocks and use the object to "expect" them in a slightly different syntax.

import org.mockito.Spy;

 @InjectMocks
 @Spy
 private MyService myService; 

And now mock the service call

 Mockito.doReturn(mockedSomeObject).when(myService).methodB();

Also change the other mock call to this

Mockito.doReturn(stuff).when(serviceA).method();
Mockito.doReturn(otherStuff).when(serviceB).method();

You must use PowerMockito.spy() instead of Mockito.spy()!

Try to import static org.powermock.api.mockito.PowerMockito.spy;

Try this:

@RunWith(MockitoJUnitRunner.class)
public class AvailabilityTest {
    @InjectMocks
    @Spy
    private Availability availability = new Availability();

    @Test
    public void testGetStockLevelStage() {
       Mockito.doReturn(expectedLong).when(availability).getStockLevelLimit();
       availability.getStockLevelStage();
    }
}

Here is an article I wrote on Mockito Spying if you need a further read.

You can set a default answer for a mock. All methods that aren't stubbed will use this default answer.

public void testUnstubbedException() {
    // Create a mock with all methods throwing a RuntimeException by default
    SomeClass someClass = mock( SomeClass .class, new RuntimeExceptionAnswer() );

    doReturn(1).when(someClass).getId(); // Must use doReturn

    int id = someClass.getId(); // Will return 1

    someClass.unstubbedMethod(); // Will throw RuntimeException
}

public static class RuntimeExceptionAnswer implements Answer<Object> {

    public Object answer( InvocationOnMock invocation ) throws Throwable {
        throw new RuntimeException ( invocation.getMethod().getName() + " is not stubbed" );
    }

}

Note that you cannot use when with this functionality, since the method is called before when (How does mockito when() invocation work?) and it will throw a RuntimeException before the mock goes into stubbing mode.

Therefore, you must use doReturn for this to work.

The idea of mocking is that you totally isolate the thing that you are testing. Then, when the test fails you can be sure where the problem is without having to hunt through the whole class dependency tree. If you are testing the behaviour of multiple classes together then this is not really unit testing.

An object factory for the tests would presumably make objects with stubbed methods, and the mocking frameworks are essentially generic object factories for use in tests. But mocks provide a lot more than stubs do - a difference which Martin Fowler goes into detail on here: http://martinfowler.com/articles/mocksArentStubs.html.

If you find mocking arduous, and you also find that you are doing a lot of it, then that is a classic example of TDD telling you that your design could be improved.

In that case, the class are not load belongs to javax.security, thus you should ignore "javax.security.*" in @PowerMockIgnore. It works.