How to use should_allow_chained_stubbing method of org.mockitousage.stubbing.StubbingWithThrowablesTest class

It means that dependency graph contains multiple dependencies with the same group and module but different versions for e.g. org.hamcrest:hamcrest-core. Gradle tries to resolve conflicted versions automatically - by default the latest version is chosen. On the left side of -> is the requested version, on the right the version that will be picked. Here similar question can be found.

Refering to this tutorial on Mockito, you can see that Mockito do call the original method.

There is only one caveat to this syntax. The real rule.createFileTemplate() method will be called once. This can have a lot of side effects and might even fail throwing an exception (very often a NPE). To solve this, you can (should?) use this alternative Mockito syntax:

doReturn(mockFileTemplate).when(rule).createFileTemplate();

In order to avoid this you should use the other syntax of Mockito doReturn().when()

doThrow(new Exception("Testing")).when(spy).methodB();

Hope this help.

EDIT :

Please notice that the structure is a little bit different than the when().thenReturn().

doThrow(new Exception("Testing"))
    .when(spy)
    .methodB();

Mockito comes with a helper class to save you some reflection boiler plate code:

import org.mockito.internal.util.reflection.Whitebox;

//...

@Mock
private Person mockedPerson;
private Test underTest;

// ...

@Test
public void testMethod() {
    Whitebox.setInternalState(underTest, "person", mockedPerson);
    // ...
}

Update: Unfortunately the mockito team decided to remove the class in Mockito 2. So you are back to writing your own reflection boilerplate code, use another library (e.g. Apache Commons Lang), or simply pilfer the Whitebox class (it is MIT licensed).

Update 2: JUnit 5 comes with its own ReflectionSupport and AnnotationSupport classes that might be useful and save you from pulling in yet another library.

I agree with what @fge said, more over. Lets look at example. Consider you have a method:

class A {
    public void foo(OtherClass other) {
        SomeData data = new SomeData("Some inner data");
        other.doSomething(data);
    }
}

Now if you want to check the inner data you can use the captor:

// Create a mock of the OtherClass
OtherClass other = mock(OtherClass.class);

// Run the foo method with the mock
new A().foo(other);

// Capture the argument of the doSomething function
ArgumentCaptor<SomeData> captor = ArgumentCaptor.forClass(SomeData.class);
verify(other, times(1)).doSomething(captor.capture());

// Assert the argument
SomeData actual = captor.getValue();
assertEquals("Some inner data", actual.innerData);

First of all the reason for mocking MyHandler methods can be the following: we already test anotherMethod() and it has complex logic, so why do we need to test it again (like a part of someMethod()) if we can just verify that it's calling?
We can do it through:

@RunWith(MockitoJUnitRunner.class)
class MyHandlerTest {

  @Spy  
  @InjectMocks  
  private MyHandler myHandler;  

  @Mock  
  private MyDependency myDependency;  

  @Test  
  public void testSomeMethod() {  
    doReturn(1).when(myHandler).anotherMethod();  
    assertEquals(myHandler.someMethod() == 1);  
    verify(myHandler, times(1)).anotherMethod();  
  }  
}  

Note: in case of 'spying' object we need to use doReturn instead of thenReturn(little explanation is here)

Always remember that the idea behind unit tests (using mocks) is to poke and prode all the dark corners of a single class. They are about making sure that the class behaves as expected for all the sorts of input you can think of. Thats why we use mocks for doing this, because we can program those mocks to do all sorts of things that might be difficult to reproduce if the class was hooked up to the rest of the application.

Integration on the other hand, has a different emphasis. It's about making sure that all your classes work together to produce the desired result. So keep that in mind when coding them. It's the big picture that you are after. You don't need to worry about obsure edge cases of individual classes because that's the job of your mocked unit tests. But things like database state are exactly why integration tests are important.

I also agree with @stivlo about using products like HSQL for in memory database work. They can both speed up integration testing and help to ensure a known starting point for a test.

I would suggest keeping your unit tests and integration tests in seperate directories or at least seperate packages named to match. Simple because it helps you to remember what you are dealing with.

Also watch out for test creep. Ie. Unit tests that are instantiating a lot of application classes and really should be moved into integration tests, and integration tests that are doing lots of detailed variation style tests on a class - candidates for a unit test. Particularly with the last you can prune a lot of time off a build if there are integration tests which should not exist.

Finally like any code, test code needs a little love and attention from time to time. So keep an eye out for refactoring opportunities. That being said, I've also seen test code that has become difficult to work with because it's too generalised and over engineered. Remember test code is not production code, so in most cases clarity is far more important than engineering. It's a balance that you will get through experience.

When involving Spring:

If you want to use Spring test framework features in your tests like for example @MockBean, then you have to use @ExtendWith(SpringExtension.class). It replaces the deprecated JUnit4 @RunWith(SpringJUnit4ClassRunner.class)

When NOT involving Spring:

If you just want to involve Mockito and don't have to involve Spring, for example, when you just want to use the @Mock / @InjectMocks annotations, then you want to use @ExtendWith(MockitoExtension.class), as it doesn't load in a bunch of unneeded Spring stuff. It replaces the deprecated JUnit4 @RunWith(MockitoJUnitRunner.class).

To answer your question:

Yes you can just use @ExtendWith(SpringExtension.class), but if you're not involving Spring test framework features in your tests, then you probably want to just use @ExtendWith(MockitoExtension.class).

It might be problem with the dependencies. The powermock-api-mockito has compile time dependency on mockito-core version 1.10.19, but you have also defined a dependency on version 2.0.44-beta. This might be a classpath problem. Try removing the explicit dependency on version 2.0.44-beta.

Yes, you are on the right track, putting a mock @Bean in a @Configuration class is one approach, and I'll describe my experience:

The trick is that you need to use a different set of .xml files purely for testing which exclude the live versions of those beans.

@ContextConfiguration(locations = {"context1-test.xml", "context2-test.xml", ...})

And the "-test-xml" files go in src/test/resources.

At least that was my experience in doing the same thing. Maybe there is some way to "override" the beans with the mock versions, but as yet I am not aware of it.

I also chose to put the mocks (I had 5 of them) all together in an own configuration:

@Configuration
public class MockServicesProvider {
     @Bean
     public AnotherBean myMock() { return mock(AnotherBean.class); }
}

Another interesting part of this problem is the common usage of initMocks(this); in the @Before method of your test class.

If the mocks are being used in other places (and they are, that's why you are wiring them up...) then initMocks(this) will blow them away between tests (not literally - just that new mocks will be created and any other mocks wired up in other objects will be "lost").

The solution to this was to call mockito's reset(mockObject) in the @Before method before each test. The same mocks are reset (all the when's and interactions), without creating new mocks.

Note that the Mockito docs for reset say very sternly that this method should not commonly be used, except in the context of mocks being applied via dependency injection, as we are indeed doing in this case :)

Have fun!