How to use AbstractThrowsExceptionTest class of org.mockito.internal.stubbing.answers package

Usually when you are unit testing, you shouldn't initialize Spring context. So remove Autowiring.

Usually when you do integration testing, you should use real dependencies. So remove mocking.

You are mixing integration and unit test here.

This took me a while to figure out, so I am answering my own question.

AFAIK, you need to "undo" each mock. Mockito.reset() will not work with Class<?> references. At the end of the test method, add:

// Undo the mock above because we need to call PathUtils.removeFile() within @After.
PowerMockito.doCallRealMethod().when(PathUtils.class);
PathUtils.removeFile(Mockito.any(File.class));

Mockito can handle chained stubs:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

AFAIK, the first method in the chain returns a mock, which is set up to return your value on the second chained method call.

Mockito's authors note that this should only be used for legacy code. A better thing to do otherwise is to push the behavior into your CacheContext and provide any information it needs to do the job itself. The amount of information you're pulling from CacheContext suggests that your class has feature envy.

If you find yourself creating test classes (other than the classes containing actual tests), then you've defeated the purpose of having a mocking framework.

Create your mocks in your testcases:

 @Test
 public void testGreetingGenerator() {
      Person mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");

      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

If you are using the same mock in many tests, by all means make the mock a field, and put the mock creation into an @Before method.

 @Before
 public void setUp() {
      mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");
 }

 @Test
 public void testGreetingGenerator() {
      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

You can create a "basic" mock in setUp() and add more mocked behaviour to it in the individual testcases. Remember that setUp() gets called before each test, so you get fresh objects in each test.

If the mock creation gets too long and complex, it's fine to move it into a method (static or otherwise), and if necessary decompose that method into lots of smaller ones.

However, if your test code gets too complicated, think of it as a warning that perhaps the unit under test has too many dependencies and needs to be redesigned for testability.

Mocking is for unit testing. In the example above, the unit I am testing is GreetingGenerator. I am not intending to test Person here, so it is better to use a mock Person than a real one. That way if something about Person breaks, my Person tests will fail but my GreetingGenerator tests will keep working.

However that means that those tests don't validate that your Person and GreetingGenerator classes interoperate properly, and that's why as well as unit tests, you should have integration tests.

If you know a class is just for value objects, there's little benefit in using a mock.

PowerMock implements its own MockMaker which leads to incompatibility with Mockito mock-maker-inline, even if PowerMock is just added as a dependency and not used. If two org.mockito.plugins.MockMaker exist in path then any only one can be used, which one is undetermined.

PowerMock can however delegate calls to another MockMaker, and for then tests are run without PowerMock. Since PowerMock 1.7.0 this can be configured with using the PowerMock Configuration.

The MockMaker can be configured by creating the file org/powermock/extensions/configuration.properties and setting:

mockito.mock-maker-class=mock-maker-inline

Example of using Mockito mock-maker-inline with PowerMock: https://github.com/powermock/powermock-examples-maven/tree/master/mockito2

What is a Junit Extension

The purpose of Junit 5 extensions is to extend the behavior of test classes or methods

source

Read on Junit 5 Extension Model & @ExtendWith annotation :here

SpringExtension

SpringExtension integrates the Spring TestContext Framework into JUnit 5's Jupiter programming model.

public class SpringExtension
extends Object
implements BeforeAllCallback, AfterAllCallback, TestInstancePostProcessor, BeforeEachCallback, AfterEachCallback, BeforeTestExecutionCallback, AfterTestExecutionCallback, ParameterResolver{..}

MockitoExtension

This extension is the JUnit Jupiter equivalent of our JUnit4 MockitoJUnitRunner

public class MockitoExtension
extends java.lang.Object
implements BeforeEachCallback, AfterEachCallback, ParameterResolver{..}

As it can be seen , SpringExtension implements a lot more extensions than MockitoExtension.

Also @SpringBootTest is meta annotated with @ExtendWith(SpringExtension.class) and which means every time your tests are extended with SpringExtension. @MockBean is a Spring test framework annotation and used along with @ExtendWith(SpringExtension.class)

To observe the difference try the following

ExtendWith only MockitoExtension

@ExtendWith(MockitoExtension.class)
class TestServiceTest {

    @MockBean
    TestService service;

    @Test
    void test() {
        assertNotNull(service); // Test will fail
    }

}

ExtendWith only SpringExtension

@ExtendWith(SpringExtension.class)
class TestServiceTest {

    @MockBean
    TestService service;

    @Test
    void test() {
        assertNotNull(service); // Test succeeds
    }

}

ExtendWith with both SpringExtension and MockitoExtension

@ExtendWith(MockitoExtension.class)
@ExtendWith(SpringExtension.class)
class TestServiceTest {

    @MockBean
    TestService service;

    @Test
    void test() {
        assertNotNull(service); // Test succeeds
    }

}

Both works in your case because of the @SpringBootTest annotation for the test class as explained.

To answer the question : When to use @ExtendWith Spring or Mockito? ,

When the test requires a Spring Test Context ( to autowire a bean / use of @MockBean ) along with JUnit 5's Jupiter programming model use @ExtendWith(SpringExtension.class). This will support Mockito annotations as well through TestExecutionListeners.

When the test uses Mockito and needs JUnit 5's Jupiter programming model support use @ExtendWith(MockitoExtension.class)

Hope this helps

Mockito verifies the order across all the mocks that were passed to the inorder function. So if you don't want to verify the order of the foos you need to create two seperate in-orders. i.e.

@Test
public void testGroupOrder() {
    Foo foo1 = mock(Foo.class);
    Foo foo2 = mock(Foo.class);
    Bar underTest = new Bar();
    underTest.addFoo(foo1);
    underTest.addFoo(foo2);

    underTest.fire()

    InOrder inOrderFoo1 = inOrder(foo1);
    inOrderFoo1.verify(foo1).doThisFirst();
    inOrderFoo1.verify(foo1).beforeDoingThis();

    InOrder inOrderFoo2 = inOrder(foo2);
    inOrderFoo2.verify(foo2).doThisFirst();
    inOrderFoo2.verify(foo2).beforeDoingThis();
}

@Spy and @InjectMocks cannot be used well together (see Google Code issue #489 and GitHub issue #169), and for what they do it is not clear or common that they should be used together at all. In well-written Mockito usage, you generally should not even want to apply them to the same object.

• @InjectMocks works as a sort of stand-in dependency injection for the system under test: If you have a test that defines a @Mock or @Spy of the right type, Mockito will initialize any fields in your @InjectMocks instance with the contents of those test fields. This might be handy if you haven't otherwise structured your system-under-test for dependency injection (or if you use a DI framework that does field injection) and you want to replace those dependencies with mocks. It can be pretty fragile—unmatched fields will be silently ignored and will remain null if not set in an initializer—but remains a decent annotation for your system under test.

• @Spy, like @Mock, is designed to set up test doubles; you should use it when you have a collaborator that you want to stub or verify. Though there are cases where you could spy on your system under test, @Spy and @Mock are meant for dependencies, and not for the functionality you are testing.

Ideally, you should not have any class that fulfills both roles in the same test, or else you may find yourself writing a test that painstakingly tests behavior that you've stubbed rather than actual production behavior. In any case it will be more difficult to tell exactly what the test covers versus the behavior you've stubbed.

Of course, this may not apply if you're trying to use Mockito to test a single method in isolation, and you want to stub calls to one method while testing the other. This can be accomplished by creating a spy of your system-under-test and mocking some of its methods to avoid calling collaborators. However, this might also be an indication that your class is violating the Single Responsibility Principle, and that you should break down the class into multiple independent classes that work together. Then, in your test, you can allow instances to have exactly one role and never need both annotations at once.

Well mockito mocks works by extending the class and overriding the method, which in your case is not possible on A.a(String). If you want this to happen you have to remove the final modifier.

Now assuming A.a(String) is not final, what you ask is completely doable with mockito:

given(mockA.a(anyString()).willAnswer(returnOfB(bInstance));

Answer<String> returnOfB(final B bInstance) {
    return new Answer<String>() {
         public String answer(Invocation invocation) {
             String arg = (String) invocation.getActualArguments()[0];
             return bInstance.b(arg);
         }
    };
}

Please note this answer has been written on a phone and might have typo, or wrong names, though you should get the idea of what should be done to achieve what you want.

Cheers