How to use shouldInjectFieldIfNoSetter method of org.mockitousage.bugs.injection.InjectMocksShouldTryPropertySettersFirstBeforeFieldAccessTest class

You haven't mocked the behavior of getId in externalDependencyObject therefore it is returning null and giving you the NPE when toString() is called on that null.

You need a when(externalDependencyObject.getId()).then...

You can do with with SpringRunner without @DataJpaTest. This worked for me:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = {DataRepository.class, EntityManager.class, 
EntityManagerFactory.class})
public class DataRepositoryTest {

    @MockBean
    private EntityManager entityManager;

    @MockBean
    private EntityManagerFactory entityManagerFactory;

    @Autowired
    private DataRepository repository;

    @Before
    public void setup() {
        Mockito.when(entityManagerFactory.createEntityManager()).thenReturn(entityManager);
    }

    @Test
    public void resultTest() {

        Query q = mock(Query.class);
        when(q.setParameter(anyString(), any())).thenReturn(q);
        when(q.getResultList()).thenReturn(createMockReponse());

        when(entityManager.createQuery(anyString())).thenReturn(q);

        Result r = repository.callQuery();


    }

}

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.

I think it requires more custom work.

verify(row, new LastCall()).saveToDatabase();

and then

public class LastCall implements VerificationMode {
    public void verify(VerificationData data) {
        List<Invocation> invocations = data.getAllInvocations();
        InvocationMatcher matcher = data.getWanted();
        Invocation invocation = invocations.get(invocations.size() - 1);
        if (!matcher.matches(invocation)) throw new MockitoException("...");
    }
}

Previous Answer:

You are right. verifyNoMoreInteractions is what you need.

verify(row).setSomething(value);
verify(row).setSomethingElse(anotherValue);
verify(row).editABunchMoreStuff();
verify(row).saveToDatabase();
verifyNoMoreInteractions(row);

If you want to mock the return result of motherFunction then you need not worry about the internal implementation of the method (which ends up calling functionVoid). What you do need to do is provide Mockito with an instruction as to what to do when the method, motherFunction is invoked, this can be achieved via the when clause with syntax;

    when(mockedObject.motherFunction()).thenReturn("Any old string");

If that misses the point of what you are attempting to achieve then look at how to mock void methods in the documentation and determine whether the use of doAnswer is applicable here, something like;

doAnswer(new Answer<Void>() {

  @Override
  public Void answer(InvocationOnMock invocation) throws Throwable {
    String output_value = invocation.getArguments()[0];
    output_value = "Not blank";
    return null;
  }
}).when(myClass2).functionVoid(anyString());

By default, Mockito uses cglib to create dynamic proxies, but for Android this will not work, because cglib generates .class files, not .dex. But starting from version 1.9.5 Mockito offers an extension point that allows replacing the proxy generation engine, so all you need is change this engine and I think Dexmaker is the best variant.

So to make it works you should just add dexmaker-mockito-1.0.jar to your project, and Mockito will use it to generate his proxies.

Try View -> Tool Windows -> Maven projects, then click the blue icon in the top left of the tool window (Reimport all Maven projects). You should be able to find the dependencies in the project view, under external libraries.

If this does not work, there is probably something wrong with your maven config (pom.xml). Try mvn clean install from the command line see if it gives any errors.

If the contract of class A includes the fact that it calls method B of an object of type C, then you should test this by making a mock of type C, and verifying that method B has been called.

This implies that the contract of class A has sufficient detail that it talks about type C (which might be an interface or a class). So yes, we're talking about a level of specification that goes beyond just "system requirements", and goes some way to describing implementation.

This is normal for unit tests. When you are unit testing, you want to ensure that each unit is doing the "right thing", and that will usually include its interactions with other units. "Units" here might mean classes, or larger subsets of your application.

Update:

I feel that this doesn't apply just to verification, but to stubbing as well. As soon as you stub a method of a collaborator class, your unit test has become, in some sense, dependent on implementation. It's kind of in the nature of unit tests to be so. Since Mockito is as much about stubbing as it is about verification, the fact that you're using Mockito at all implies that you're going to run across this kind of dependency.

In my experience, if I change the implementation of a class, I often have to change the implementation of its unit tests to match. Typically, though, I won't have to change the inventory of what unit tests there are for the class; unless of course, the reason for the change was the existence of a condition that I failed to test earlier.

So this is what unit tests are about. A test that doesn't suffer from this kind of dependency on the way collaborator classes are used is really a sub-system test or an integration test. Of course, these are frequently written with JUnit too, and frequently involve the use of mocking. In my opinion, "JUnit" is a terrible name, for a product that lets us produce all different types of test.

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!