How to use validates_listeners method of org.mockito.internal.creation.DelegatingMethodTest class

I got this exception even though I had a public method annotaded with @Test. Turned out was importing org.junit.jupiter.api.Test, I changed to org.junit.Test and it worked fine.

There is more than one possible argument matcher and one is eq, which is mentioned in the exception message. Use:

verify(function, times(1)).doSomething(eq(arg1), any(Argument2.class));

(static imports supposed to be there -- eq() is Matchers.eq()).

You also have same() (which does reference equality, ie ==), and more generally you can write your own matchers.

You are looking for an ArgumentCaptor:

  Mock mock =  Mockito.mock(Mock.class);
  ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
  mock.method("input");
  Mockito.verify(mock).method(captor.capture());
  String actualValue = captor.getValue();

You can use

  Mockito.doAnswer(new Answer<Void>() {
        @Override
        public Void answer(InvocationOnMock invocation) throws Throwable {
            //DO SOMETHING
            return null;
        }
    }).when(...).remove(Matchers.<String>anyVararg());

From the Javadoc:

Use doAnswer() when you want to stub a void method with generic Answer.

Stubbing voids requires different approach from Mockito.when(Object) because the compiler does not like void methods inside brackets...

Example:

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

See examples in javadoc for Mockito

I will answer the question in two parts. First, yes it is code smell to mock or spy the class under test. That does not mean that it cannot be done correctly but that it is risk prone and should be avoided whenever possible.

WRT your specific example, I would see how the spy could be correctly used but that would be predicated on the assertion that you have elsewhere fully unit tested getStringMetadata. This then begs the question, if you have fully unit tested getStringMetadata elsewhere then you must know how to test it and therefore why not test getNumLines without the spy.

All this being said, millhouse makes a good point but either way you have to unit test the expensive code somewhere. His suggestion goes a long way to help isolate the expensive code and ensure that you only have to test / exercise it once.

UPDATE

There are newer java7 versions that fix this issue. As is written in reply to Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7 #525

upgrading from java 7u71 to 7u75 fixed the problem

Rootcause

Upon investigation I heard cries for help from all over the internet from all tools and languages that built upon JDK.

Turns out the cause is new java bytecode standard that gets checked by new verifier. But unfortunately javassist sometimes is asked by powermock to produce changes into bytecode that are no longer accepted by this new shiny veryfier.

Workaround (for those who cannot go with newer java)

As a workaround in JRebel blog they suggested using -noverify flag upon starting JVM However i found from Java 7 Bytecode Verifier: Huge backward step for the JVM blog post alternative workaround that works on java7: -XX:-UseSplitVerifier

As my tests run in some unaccessible server and are executed as part of maven build, i needed to find a way to pass that argument along with my project files. First workable solution i discovered is to add this parameter to configurtaion of surefire plugin in pom.xml as follows:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.10</version>
            <configuration>
                <argLine>-XX:-UseSplitVerifier</argLine>
            </configuration>
        </plugin>
        <plugin>
    </plugins>
</build>

I suppose that on java8 one could use similar method to call tests with -noverify key, but haven't had the chance to confirm that.

Other related resources to keep eye on

Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7. Powermock / Javassist creates illegal constructors for JDK 1.7.0u65 and 1.8.0u11 with -target 7 #525

I think the answer is no -- perhaps you could pull it off with some intense reflection wrangling, but if so I don't think it would be worth your time.

But I think (without seeing your method), you can probably still get full coverage on your method:

• If your method takes any action after catching the exception, assert or verify that those actions happened.
  
  
• If no action happens after catching the exception, assert or verify that whatever actions were supposed to happen but were cut off by the exception, didn't happen.
  
  
• Finally, (again, not seeing your method I don't know exactly what you're dealing with) if your method is void, and nothing happens after catching the exception, and the last line of logic is what can throw the exception, then consider making your method return a boolean, have it return false if the exception is caught and true otherwise. Then in your test, make a scenario that should cause the exception to be thrown and caught, and test that the method returns false.
  
  

The problem with using RETURN_DEEP_STUBS is that you'll get a different mock each time you call a method. I think from your question that you want to use a default Answer that actually returns the mock on which it was called, for each method that has the right return type. This could look something like the following. Note that I haven't tested this, so it may contain typos, but I hope that the intention is clear in any case.

import static org.mockito.Mockito.RETURNS_DEFAULTS;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

public class SelfReturningAnswer implements Answer<Object> {

    public Object answer(InvocationOnMock invocation) throws Throwable {
        Object mock = invocation.getMock();
        if(invocation.getMethod().getReturnType().isInstance(mock)){
            return mock;
        }
        return RETURNS_DEFAULTS.answer(invocation);
    }
}

Then, when you create your mock, specify this as your default answer. This will make your mock return itself from each method that it can; but it will behave like an ordinary mock when you call a method whose return type is wrong for the mock.

Create your mock like this

Builder mockBuilder = mock( Builder.class, new SelfReturningAnswer());

or create a constant for this class and write something like

@Mock(answer = SELF_RETURNING) private Builder mockBuilder;

Hope that helps.

Since you are loading configuration class MyApplication.class datasource bean will be created, Try moving datasource in another bean which is not used in a test, make sure all classes loaded for tests are not dependant on datasource.
Or
In your tests create a config class marked with @TestConfiguration and include it in SpringBootTest(classes=TestConfig.class) mocking data source there like

@Bean
public DataSource dataSource() {
    return Mockito.mock(DataSource.class);
}

But this may fail since method call to this mocked datasouce for connection will return null, In that case, you'll have to create an in-memory datasource and then mock jdbcTemplate and rest of dependencies.