How to use RuntimeException method of org.mockito.internal.handler.InvocationNotifierHandlerTest class

You can do it with Mockito and PowerMockito.

Say you have ClassUnderTest with a constructor

public class ClassUnderTest {
    String name;
    boolean condition;

    public ClassUnderTest(String name, boolean condition) {
       this.name = name;
       this.condition = condition;
       init();
    }

    ...
}

And another class that calls that constructor

public class MyClass {

    public MyClass() { } 

    public void createCUTInstance() {
       // ...
       ClassUnderTest cut = new ClassUnderTest("abc", true);
       // ...
    }

    ...
}

At the Test class we could...

(1) use PowerMockRunner and cite both target classes above in the PrepareForTest annotation:

@RunWith(PowerMockRunner.class)
@PrepareForTest({ ClassUnderTest.class, MyClass.class })
public class TestClass {

(2) intercept the constructor to return a mock object:

@Before
public void setup() {
    ClassUnderTest cutMock = Mockito.mock(ClassUnderTest.class);
    PowerMockito.whenNew(ClassUnderTest.class)
                .withArguments(Matchers.anyString(), Matchers.anyBoolean())
                .thenReturn(cutMock);
}

(3) validate the constructor call:

@Test
public void testMethod() {
    // prepare
    MyClasss myClass = new MyClass();

    // execute
    myClass.createCUTInstance();

    // checks if the constructor has been called once and with the expected argument values:
    String name = "abc";
    String condition = true;
    PowerMockito.verifyNew(ClassUnderTest.class).withArguments(name, condition);
}

The mocks that Mockito creates are generated class files; however, Mockito is designed for use in a JVM, so out of the box it generates .class files using cglib. Android Instrumentation test cases run on devices or emulators, so they need Dalvik .dex files.

You'll need to ensure you're including DexMaker on your classpath. The dexmaker-mockito Maven project seems to be right, though it depends on Mockito 1.10.5, which is a few versions behind at this point.

As a side note, unless you use the Android Testing Support Library, you will need to use JUnit3 semantics. You will not be able to use @Rule fields or custom test runners; you will also need to override setUp and tearDown (as opposed to @Before and @After annotations) and name your tests as testFooBar (as opposed to @Test annotations).

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.

From the link you posted;

Default answer of every Mockito mock.

• Returns appropriate primitive for primitive-returning methods
• Returns consistent values for primitive wrapper classes (e.g. int-returning method retuns 0 and Integer-returning method returns 0, too)
• Returns empty collection for collection-returning methods (works for most commonly used collection types)
• Returns description of mock for toString() method
• Returns null for everything else

From the FAQ:

What values do mocks return by default?

In order to be transparent and unobtrusive all Mockito mocks by default return 'nice' values. For example: zeros, falseys, empty collections or nulls.

It was probably done to stay consistent with any other methods which return null for any other non-collection, non-primitive Wrapper objects.

You can always implement your own Answer to pass to mock which returns empty strings for String returning methods.

I would avoid it. Generally speaking, you should structure things as best you can to avoid needing to test private variables and stick with the interactions that the rest of the application will be exposed to. This is typically public methods/properties and protected methods by using fakes/doubles.

The purpose of the unit tests are to verify how the object under test is interacted with, not necessarily it's implementation details. Basically, with input x, I should get output/effect y. If you get hung up on testing exactly how x produces y, you run the risk of making your classes inflexible to change. Every refactor of your class is likely to break your tests, even if the output and end result is the same.

Matchers.any(Class) will do the trick:

Mockito.when(object.doThings(Matchers.any(MyEnum.class), Matchers.anyLong()))
    .thenReturn(123L);

null will be excluded with Matchers.any(Class). If you want to include null you must use the more generic Matchers.any().

As a side note: consider using Mockito static imports:

import static org.mockito.Matchers.*;
import static org.mockito.Mockito.*;

Mocking gets a lot shorter:

when(object.doThings(any(MyEnum.class), anyLong())).thenReturn(123L);

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 can use Mockito's Answer to mock the stream.

    String expectedContents = "Some contents";
    InputStream testInputStream = new StringInputStream(expectedContents);
    S3ObjectInputStream s3ObjectInputStream = mock(S3ObjectInputStream.class);
    S3Object s3Object = mock(S3Object.class);
    AmazonS3Client amazonS3Client = mock(AmazonS3Client.class);
    S3AttachmentsService service = new S3AttachmentsService(amazonS3Client);

    when(s3ObjectInputStream.read(any(byte[].class))).thenAnswer(invocation -> {
        return testInputStream.read(invocation.getArgument(0));
    });

I have a more extensive example here. Hope that helps.

You're nesting mocking inside of mocking. You're calling getSomeList(), which does some mocking, before you've finished the mocking for MyMainModel. Mockito doesn't like it when you do this.

Replace

@Test
public myTest(){
    MyMainModel mainModel =  Mockito.mock(MyMainModel.class);
    Mockito.when(mainModel.getList()).thenReturn(getSomeList()); --> Line 355
}

with

@Test
public myTest(){
    MyMainModel mainModel =  Mockito.mock(MyMainModel.class);
    List<SomeModel> someModelList = getSomeList();
    Mockito.when(mainModel.getList()).thenReturn(someModelList);
}

To understand why this causes a problem, you need to know a little about how Mockito works, and also be aware in what order expressions and statements are evaluated in Java.

Mockito can't read your source code, so in order to figure out what you are asking it to do, it relies a lot on static state. When you call a method on a mock object, Mockito records the details of the call in an internal list of invocations. The when method reads the last of these invocations off the list and records this invocation in the OngoingStubbing object it returns.

The line

Mockito.when(mainModel.getList()).thenReturn(someModelList);

causes the following interactions with Mockito:

• Mock method mainModel.getList() is called,
• Static method when is called,
• Method thenReturn is called on the OngoingStubbing object returned by the when method.

The thenReturn method can then instruct the mock it received via the OngoingStubbing method to handle any suitable call to the getList method to return someModelList.

In fact, as Mockito can't see your code, you can also write your mocking as follows:

mainModel.getList();
Mockito.when((List<SomeModel>)null).thenReturn(someModelList);

This style is somewhat less clear to read, especially since in this case the null has to be casted, but it generates the same sequence of interactions with Mockito and will achieve the same result as the line above.

However, the line

Mockito.when(mainModel.getList()).thenReturn(getSomeList());

causes the following interactions with Mockito:

1. Mock method mainModel.getList() is called,
2. Static method when is called,
3. A new mock of SomeModel is created (inside getSomeList()),
4. Mock method model.getName() is called,

At this point Mockito gets confused. It thought you were mocking mainModel.getList(), but now you're telling it you want to mock the model.getName() method. To Mockito, it looks like you're doing the following:

when(mainModel.getList());
// ...
when(model.getName()).thenReturn(...);

This looks silly to Mockito as it can't be sure what you're doing with mainModel.getList().

Note that we did not get to the thenReturn method call, as the JVM needs to evaluate the parameters to this method before it can call the method. In this case, this means calling the getSomeList() method.

Generally it is a bad design decision to rely on static state, as Mockito does, because it can lead to cases where the Principle of Least Astonishment is violated. However, Mockito's design does make for clear and expressive mocking, even if it leads to astonishment sometimes.

Finally, recent versions of Mockito add an extra line to the error message above. This extra line indicates you may be in the same situation as this question:

3: you are stubbing the behaviour of another mock inside before 'thenReturn' instruction if completed