How to use SpyWithConstructorTest class of org.mockitoinline package

You can't instantiate an abstract class directly, but you can easily instantiate an anonymous subclass, and that's pretty trivial in this case as you're not forced to define any methods:

Mockito.when(mockDAO.getDatabaseResults()).thenThrow(new ProblemException(){});

Alternatively, you can just use another mock:

Mockito.when(mockDAO.getDatabaseResults()).thenThrow(Mockito.mock(ProblemException.class));

This would make sense if the abstract class forced the definition of other methods you don't care about in your test.

You can mock it using PowerMock in combination with Mockito:

On top of your class:

@RunWith(PowerMockRunner.class)
@PrepareForTest({ClassThatCallsTheCalendar.class})

The key to success is that you have to put the class where you use Calendar in PrepareForTest instead of Calendar itself because it is a system class. (I personally had to search a lot before I found this)

Then the mocking itself:

mockStatic(Calendar.class);
when(Calendar.getInstance()).thenReturn(calendar);

First, create a ResponseEntity object:

HttpHeaders header = new HttpHeaders();
header.setContentType(MediaType.APPLICATION_JSON);

ResponseEntity<?> responseEntity = new ResponseEntity<>(
    "some response body",
    header, 
    HttpStatus.OK
);

Then build a mock to return the responseEntity object:

when(restC.SomeMethod(client)).thenReturn(responseEntity);

---

Point to pay attention:

Avoid to use ResponseEntity inside @Service class. You should use ResponseEntity in @RestController class.

And you can Inject your @Service class using @Autowired annotation, like:

@RestController
public class YourControllerClass {

    @Autowired
    private YourServiceClass yourServiceClass;

Or using constructor, like:

@RestController
public class YourControllerClass {

    private YourServiceClass yourServiceClass;

    public YourControllerClass(YourServiceClass yourServiceClass) {
        this.yourServiceClass= yourServiceClass;
    }

So:

@Service class will handle business or data objects and @RestController class will handle Response and Request objects. Thus we have Single Responsibility principle.

---

Some nice links:

• Spring MVC - Using RequestEntity and ResponseEntity
• How do I mock a REST template
• Building REST services with Spring
• Understanding the Single Responsibility Principle

Hope this 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

In this sort of situation, I would use physical files for testing the component and not rely on a mocking framework. As fge mentions it may be easier plus you don't have to worry about any incorrect assumptions you may make of your mock.

For instance, if you rely upon File#listFiles() you may have your mock return a fixed list of Files, however, the order they are returned in is not guaranteed - a fact you may only discover when you run your code on a different platform.

I would consider using JUnit's TemporaryFolder rule to help you set up the file and directory structure you need for your test, e.g.:

public class DummyFileClassTest {
    @Rule
    public TemporaryFolder folder = new TemporaryFolder();

    @Test
    public void someMethod() {
        // given
        final File file1 = folder.newFile("myfile1.txt");
        final File file2 = folder.newFile("myfile2.txt");

        ... etc...
    }
}

The rule should clean up any created files and directories when the test completes.

After posting the question I found the answer, it seems to be a problem with version 1.6.5, it needs an additional dependency, it's described here.

The dependency is powermock-api-mockito-common version 1.6.5, you can either add it to you pom.xml

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito-common</artifactId>     
    <version>1.6.5</version>
</dependency>

or download the jar

For functions returning void, use doAnswer()

doAnswer(...).when(mockedObject).handle(any(Callback[].class));

And an Answer that performs the interception must go in as the parameter to doAnswer, e.g. as an anonymous class:

new Answer() {
  public Object answer(InvocationOnMock invocation) {
      Object[] args = invocation.getArguments();
      Mock mock = invocation.getMock();
      return null;
  }}

In this case args will be the array Callback[]!

Try the anyVararg() matcher. This was introduced in 1.8.1.

use

MockitoAnnotations.openMocks(this);