How to use shouldMixVerificationInOrderAndOrdinaryVerification method of org.mockitousage.verification.BasicVerificationInOrderTest class

when(
  fooDao.getBar(
    any(Bazoo.class)
  )
).thenReturn(myFoo);

or (to avoid nulls):

when(
  fooDao.getBar(
    (Bazoo)notNull()
  )
).thenReturn(myFoo);

Don't forget to import matchers (many others are available):

For Mockito 2.1.0 and newer:

import static org.mockito.ArgumentMatchers.*;

For older versions:

import static org.mockito.Matchers.*;

Generally, don't mock the class under test. If your test is for a Person, you shouldn't ever see Mockito.mock(Person.class) in it, as that's a pretty clear sign that you're testing the mocking framework instead of the system-under-test.

Instead, you may want to create a spy(new Person()), which will create a real Person implementation using a real constructor and then copy its data to a Mockito-generated proxy. You can use MockingDetails.getInvocations() to reflectively check that every getter was called.

// This code is untested, but should get the point across. Edits welcome.
// 2016-01-20: Integrated feedback from Georgios Stathis. Thanks Georgios!

@Test
public void callAllGetters() throws Exception {
  Person personSpy = spy(new Person());
  personSpy.getFirstname();
  personSpy.getLastname();

  assertAllGettersCalled(personSpy, Person.class);
}

private static void assertAllGettersCalled(Object spy, Class<?> clazz) {
  BeanInfo beanInfo = Introspector.getBeanInfo(clazz);
  Set<Method> setOfDescriptors = beanInfo.getPropertyDescriptors()
      .stream()
      .map(PropertyDescriptor::getReadMethod)
      .filter(p -> !p.getName().contains("getClass"))
      .collect(Collectors.toSet());
  MockingDetails details = Mockito.mockingDetails(spy);
  Set<Method> setOfTestedMethods = details.getInvocations()
      .stream()
      .map(InvocationOnMock::getMethod)
      .collect(Collectors.toSet());
  setOfDescriptors.removeAll(setOfTestedMethods);
  // The only remaining descriptors are untested.
  assertThat(setOfDescriptors).isEmpty();
}

There might be a way to call verify and invoke on the Mockito-generated spy, but that seems very fragile, and very dependent on Mockito internals.

As an aside, testing bean-style getters seems like an odd use of time/effort. In general focus on testing implementations that are likely to change or break.

It's a bug: https://github.com/spring-projects/spring-boot/issues/6541

The fix is in spring-data 1.0.2-SNAPSHOT and 2.0.3-SNAPSHOT : https://github.com/arangodb/spring-data/issues/14#issuecomment-374141173

If you aren't using these version, you can work around it by declaring the mock with its name:

@MockBean(name="myMongoRepository")
private MyMongoRepository repository;

---

In response to your comment

From Spring's doc:

For convenience, tests that need to make REST calls to the started server can additionally @Autowire a TestRestTemplate which will resolve relative links to the running server.

Reading this, I think you need to declare @SpringBootTest with a web environment:

@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)

If your spring boot doesn't start the web environment, then what is the need for TestRestTemplate. Thus, I guess spring does not even make it available.

You can use MockingDetails and either printInvocations or getInvocations to inspect the interactions belonging to a mock. However, this will not produce a list of invocations belonging to multiple mocks in the order that happened: just interactions with each individual mock.

Code snippet, as contributed by elhefe and Anand Rockzz:

import static org.mockito.Mockito.mockingDetails;

System.out.println(mockingDetails(mock).printInvocations());
/* or */
System.out.println(mockingDetails(mock).getInvocations());

Acknowledging your reluctance and caveats in the comments, I would say that this is a technique that does more to lock in your current implementation than to analyze your real constraints and prevent regressions. Furthermore, if your algorithm has a lot of interactions with direct collaborators, that might be an indication that the algorithm should be refactored.

If the system is untested or undocumented legacy code, this might be a practical way to programmatically generate a regression test or analysis--a temporary starting point for more-informed regression testing--but in your shoes I would instead start by documenting the contract of each component and then writing a test that confirms those interactions and constraints. Mockito recommendations (as intimated through this article by Mockito's original developer) tend toward adding stubs until tests pass and adding verifications/counts only where there are expensive or non-idempotent side effects.

I also faced the same problem.

And finally, I found argThat() will return null, and normally the argument in the function in kotlin, does not accept null type.

The source code of argThat from ArgumentMatchers.java

public static <T> T argThat(ArgumentMatcher<T> matcher) {
    reportMatcher(matcher);
    return null;
}

You can see that it return null. So when we mock the function, it will throw IllegalStateException, because argThat returns null and argument can't be null.

It mean that if your function is:

fun doSomething(arg1: String): Int {
    // do something
}

When you mock it like that:

Mockito.`when`(
    doSomething(Mockito.argThat<String> { true })
).thenReturn(100)

It will throw IllegalStateException

So you should change your function like that:

fun doSomething(arg1: String?): Int {
    // do something
}

Change the "String" to "String?", make it accept null type.

My solution is to define the argument with class? so that it can accept null, but I don't know if it is a great solution

Mockito, till version 1.8.5, had a bug in the case of polymorphic dispatch. It was fixed and is available in the first release candidate of the version 1.9.0. See issue 200.

So how does it happen in your code base. Note you are mocking these two classes

nodeAutoIndexer = (AutoIndexer<Node>) mock(AutoIndexer.class);
relAutoIndexer = mock(RelationshipAutoIndexer.class);

AutoIndexer happen to be a generic parent interface, in this interface there is this method ReadableIndex<T> getAutoIndex(). RelationshipAutoIndexer is a subtype of the AutoInexer where the generic part is fixed to Relationship, and override the getAutoIndex() method to return the covariant type ReadableRelationshipIndex.

See AutoIndexer and RelationshipIndexer.

Well, in your calling code you have these lines:

AutoIndexer<Node> nodeAutoIndexer = this.graphDb.index().getNodeAutoIndexer();
AutoIndexer<Relationship> relAutoIndexer = this.graphDb.index().getRelationshipAutoIndexer();
this.nodeIndex = nodeAutoIndexer.getAutoIndex();
this.relIndex = relAutoIndexer.getAutoIndex();

Both nodeAutoIndex in your production code and the mock nodeAutoIndexer in your test code have a reference of type AutoIndexer<Node>, so there's no problem regarding polymorphic dispatch. However relAutoIndex in your production code is referenced by the type AutoIndexer<Relationship> and the mock relAutoIndexer in your test code is referenced by the type RelationshipAutoIndexer, so the wrong call is registered on the mock and then fails verification.

Your solution is either to upgrade the mockito version; the 1.9.0 RC1 is very stable and a final release should be coming your way. Or you can migrate your reference type (in your production code) from :

AutoIndexer<Relationship> relAutoIndexer = this.graphDb.index().getRelationshipAutoIndexer();

to :

RelationshipAutoIndexer relAutoIndexer = this.graphDb.index().getRelationshipAutoIndexer();

---

A few other remarks.

• You don't actually need to write an after method here as JUnit creates a new instance on each method run, so your method just adds code that will be done anyway. Note this isn't the case with TestNG.

• Instead of creating your mocks in the before method, you might want to use Mockito annotations. Don't forget the runner.

For example :

@RunWith(MockitoJUnitRunner.class)
public class YourTest {
    @Mock SomeType someTypeMock;
    // ...
}

• The stubbing code is a bit ugly for several reasons.

  • Your should write consistent stubs.

Why not write this in a cleaner way; for example referencing indexManager in both case :

IndexManager indexManager = mock(IndexManager.class);
when(graphDb.index()).thenReturn(indexManager);
when(indexManager.getNodeAutoIndexer()).thenReturn(nodeAutoIndexer);
when(indexManager.getRelationshipAutoIndexer()).thenReturn(relAutoIndexer);

Or don't reference it at all

IndexManager indexManager = mock(IndexManager.class);
when(graphDb.index()).thenReturn(indexManager);
when(graphDb.index().getNodeAutoIndexer()).thenReturn(nodeAutoIndexer);
when(graphDb.index().getRelationshipAutoIndexer()).thenReturn(relAutoIndexer);

Also having a mock that returns a mock is usually a sign of design smell. You are breaking the law of Demeter, and breaking it means you will experience difficult testing, bad maintainability, and difficult evolution. When I say that you could hear me whisper also (without the syllogisms) : it will cost you money. Don't write legacy code! If you are practicing TDD or BDD, you will identify these issues at design time for your own code, which is great to prevent them.

• However if you are dealing with legacy code, you can use this deep stubs syntax :

Using the static methods you could write this

GraphDatabaseService graphdb = mock(GraphDatabaseService.class, RETURNS_DEEP_STUBS);

Or using the annotation you could write this :

@Mock(answer = RETURNS_DEEP_STUBS) GraphDatabaseService graphdb;

And the stubbing :

when(graphDb.index().getNodeAutoIndexer()).thenReturn(nodeAutoIndexer);
when(graphDb.index().getRelationshipAutoIndexer()).thenReturn(relAutoIndexer);

I've needed this several times as well. I've put together a small sample below, which you'd want to adjust to your needs. Basically, you create your own Appender and add it to the logger you want. If you'd want to collect everything, the root logger is a good place to start, but you can use a more specific if you'd like. Don't forget to remove the Appender when you're done, otherwise you might create a memory leak. Below I've done it within the test, but setUp or @Before and tearDown or @After might be better places, depending on your needs.

Also, the implementation below collects everything in a List in memory. If you're logging a lot you might consider adding a filter to drop boring entries, or to write the log to a temporary file on disk (Hint: LoggingEvent is Serializable, so you should be able to just serialize the event objects, if your log message is.)

import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MyTest {
    @Test
    public void test() {
        final TestAppender appender = new TestAppender();
        final Logger logger = Logger.getRootLogger();
        logger.addAppender(appender);
        try {
            Logger.getLogger(MyTest.class).info("Test");
        }
        finally {
            logger.removeAppender(appender);
        }

        final List<LoggingEvent> log = appender.getLog();
        final LoggingEvent firstLogEntry = log.get(0);
        assertThat(firstLogEntry.getLevel(), is(Level.INFO));
        assertThat((String) firstLogEntry.getMessage(), is("Test"));
        assertThat(firstLogEntry.getLoggerName(), is("MyTest"));
    }
}

class TestAppender extends AppenderSkeleton {
    private final List<LoggingEvent> log = new ArrayList<LoggingEvent>();

    @Override
    public boolean requiresLayout() {
        return false;
    }

    @Override
    protected void append(final LoggingEvent loggingEvent) {
        log.add(loggingEvent);
    }

    @Override
    public void close() {
    }

    public List<LoggingEvent> getLog() {
        return new ArrayList<LoggingEvent>(log);
    }
}

Yes. You've misused verify. The argument to verify has to be the mock itself. Then you call the method you want to verify on the value that's returned by verify. So in this case, the first verify call should be

Mockito.verify(_client).resource(_baseUrl + "token");

and similarly for the other verify calls.

You can use Qualifier in addition to @MockBean in case you have multiple beans of same type.

 @MockBean
 @Qualifier("centroDeCustoServiceImpl"
 private CentroDeCustoService service;

Refer MockBean java docs here:

https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/test/mock/mockito/MockBean.html

Also as per first comment to your question, you can avoid test configuration in the CentroDeCustoServiceImplTeste Unit Test. You can use a MockitoJunitRunner