How to use should_deal_with_junit_assertion_error method of org.mockito.internal.verification.VerificationOverTimeImplTest class

I think the reason may be that mock object libraries typically create mocks by dynamically creating classes at runtime (using cglib). This means they either implement an interface at runtime (that's what EasyMock does if I'm not mistaken), or they inherit from the class to mock (that's what Mockito does if I'm not mistaken). Both approaches do not work for static members, since you can't override them using inheritance.

The only way to mock statics is to modify a class' byte code at runtime, which I suppose is a little more involved than inheritance.

That's my guess at it, for what it's worth...

I know this thread is old, but it's good to add that since 2014 and this pull request, you can use the @PowerMockRunnerDelegate annotation to "delegate" the run context to SpringJUnit4ClassRunner (or any other runner really).

Above code would look like :

@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)
@PrepareForTest(X.class);
public class MyTest {

    // Tests goes here
    ...
}

With this annotation, you don't need the PowerMock rule anymore !

According to https://groups.google.com/forum/?fromgroups#!topic/mockito/9WUvkhZUy90, you should rephrase your

when(bar.getFoo()).thenReturn(fooBar)

to

doReturn(fooBar).when(bar).getFoo()

The rule S2699 (Tests should include assertions) from the SonarQube Java Analyzer does not perform cross-procedural analysis and only explore body of methods being identified as test method (usually annotated with @Test).

Consequently, if the only assertions which will be called when executing the test method are done by a dedicated method (to avoid duplication), then the rule will raise an issue. This is a known limitation of the rule and we will deal with it only when we will be able to efficiently perform cross-procedural analysis.

Regarding the issues raised by SonarQube on such cases, you can safely mark them as Won't Fix.

Regarding the detected assertions, the rule consider as assertions the usual assert/fail/verify/expect methods from the following (unit test) frameworks :

• JUnit
• Fest (1.x & 2.x)
• AssertJ
• Hamcrest
• Mockito
• Spring
• EasyMock

Okey, found the answer, you need to call to

@PrepareForTest(Foo.class)

instead of

@PrepareForTest(Bar.class)

You could use a custom answer to do this

MyInterface myMock = mock(MyInterface.class);
Sky sky = buildRandomSkyColor();

when(myMock.methodWithNoArguments()).thenAnswer(new Answer<String>(){
    String answer(InvocationOnMock invocation) {
        if(sky.isBlue())
            return "blue";
        else
            return "gray";
    }
}

Spring uses commons-logging which auto-detects the logging framework to use. There are various ways to tune which logging framework will be chosen so the first thing to do is to make sure commons-logging binds to log4j.

To do that, start your application with an additional flag -Dorg.apache.commons.logging.diagnostics.dest=STDOUT that will output the result of the discovery process.

commons-logging delegate to log4j

You now need to make sure that log4j is initialise with the expected configuration. By default, log4j searches for a log4j.xml file at the root of the classpath and fallbacks to log4j.properties if it does not find one. It could be possible that one of the library you are using has (wrongly) a log4j.xml file at the root.

To debug log4j, run your application again with an additional flag -Dlog4j.debug=true. This will output the exact loggers and the location of the configuration file.

commons-logging does not delegate to log4j

If commons-logging does not delegate to log4j, this means that another logging framework is involved. The most common scenario is that your application ships with jcl-over-slf4j.jar, a drop-in replacement of commons-logging that uses slf4j behind the scene.

In this scenario, Spring uses commons-logging that is configured to delegate to slf4j. So, essentially, Spring is using slf4j. But slf4j is a simple logging facade and needs a binding to an actual framework.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

Once you have found the binding library (it could be logback or log4j for instance), check the configuration of the logging framework that slf4j is bound to.

In this particular case, you probably have logback in your classpath. As it is a pure implementation of slf4j, it does not need a binding library and it logs in debug if no configuration file is provided, which matches your problem actually. To fix your issue, exclude logback from your dependencies and add slf4j-log4j12 to configure slf4j with log4j.

Edit: updated with various comments

This stub is wrong :

doNothing().when(mockObject.methodToStub(captor.capture())); // wrong

methodToStub(...) must be outside the when if using this API style (it should only contain the mock) :

doNothing().when(mockObject).methodToStub(captor.capture()); // correct

Tho remarks however :

1. doNothing is the default for void methods for a mock.
2. You can use the BDDMockito aliases that enables your code to be real à la Behavior Driven Development

The code you posted works for me with the latest version of Mockito and Powermockito. Maybe you haven't prepared A? Try this:

A.java

public class A {
     private final String test;

    public A(String test) {
        this.test = test;
    }

    public String check() {
        return "checked " + this.test;
    }
}

MockA.java

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

@RunWith(PowerMockRunner.class)
@PrepareForTest(A.class)
public class MockA {
    @Test
    public void test_not_mocked() throws Throwable {
        assertThat(new A("random string").check(), equalTo("checked random string"));
    }
    @Test
    public void test_mocked() throws Throwable {
         A a = mock(A.class); 
         when(a.check()).thenReturn("test");
         PowerMockito.whenNew(A.class).withArguments(Mockito.anyString()).thenReturn(a);
         assertThat(new A("random string").check(), equalTo("test"));
    }
}

Both tests should pass with mockito 1.9.0, powermockito 1.4.12 and junit 4.8.2