How to use logs_mismatch method of org.mockito.internal.junit.ArgMismatchFinderTest class

I found that RxJava provides a class called TestSubject

You can create it like this

private TestScheduler eventsScheduler = new TestScheduler();
private TestSubject<MyEvent> eventObservable = TestSubject.create(eventsScheduler);

This will provide you with the method hasObservers() which returns a boolean.

@Test
public void testSubscription(){
    myTestClass.init(eventObservable);

    assertTrue(eventObservable.hasObservers());
}

Also the TestSubject allows you to perfectly time when events should be sent.

eventObservable.onNext(new MyEvent());
eventsScheduler.triggerActions(); 

@Mock creates a mock. @InjectMocks creates an instance of the class and injects the mocks that are created with the @Mock (or @Spy) annotations into this instance.

Note you must use @RunWith(MockitoJUnitRunner.class) or Mockito.initMocks(this) to initialize these mocks and inject them (JUnit 4).

With JUnit 5, you must use @ExtendWith(MockitoExtension.class).

@RunWith(MockitoJUnitRunner.class) // JUnit 4
// @ExtendWith(MockitoExtension.class) for JUnit 5
public class SomeManagerTest {

    @InjectMocks
    private SomeManager someManager;

    @Mock
    private SomeDependency someDependency; // this will be injected into someManager
 
     // tests...

}

You should PrepareForTest the Foo class:

@PrepareForTest(Foo.class)
@RunWith(PowerMockRunner.class)
public class ...

I'm not sure how spy behaves for static methods, so I prefer to use mockStatic:

PowerMockito.mockStatic(LocalDate.class);
when(LocalDate.now())....

To make the code more testable and don't depend on mocking static methods, you could also refactor your code to use a java.time.Clock:

public class Foo {

    private Clock clock;

    public Foo() {
        // use the system's default clock
        this(Clock.systemDefaultZone());
    }

    public Foo(Clock clock) {
        // use a custom clock
        this.clock = clock;
    }

    public LocalDate getRightNow() {
        final LocalDate rightNow = LocalDate.now(this.clock);
        return rightNow;
    }
}

If you don't specify a Clock, it'll use the system's default (exactly what the now() method does when called without parameters).

Then, in your test, you create a Clock that always return the same date and pass it to the Foo class. In this case, you won't need all the PowerMockito stuff:

public class UserTest {

    @Test
    public void nowShouldReturnSameYear() throws Exception {
        LocalDate parse = LocalDate.parse("2008-04-04");
        // create a fixed clock (it always return the same date, using the system's default timezone)
        ZoneId zone = ZoneId.systemDefault();
        Clock clock = Clock.fixed(parse.atStartOfDay(zone).toInstant(), zone);

        Foo foo = new Foo(clock);
        assertEquals(parse.getYear(), foo.getRightNow().getYear());
    }
}

You can easily create your own HandlerMethod without mocking. There's a constructor that accepts an Object (the controller) and a Method (the controller method). The easiest way to get a Method is to simply call Class.getMethod(). What you want to do is just create a dummy controller class, and then use that class to get the method. For example

class TestController {
    @Custom
    public void testMethod() {}
}

Method method = TestController.class.getMethod("testMethod");
TestController controller = new TestController();
HandlerMethod handlerMethod = new HandlerMethod(controller, method);

Custom annotation = handlerMethod.getMethodAnnotation(Custom.class);

It's that easy. Below is a complete test.

public class HandlerInterceptorTest {

    @Target(ElementType.METHOD)
    @Retention(RetentionPolicy.RUNTIME)
    private @interface Custom {
    }

    private static class MyHandlerInterceptor implements HandlerInterceptor {

        @Override
        public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) {
            if (handler instanceof HandlerMethod) {
                HandlerMethod handlerMethod = (HandlerMethod) handler;
                Custom annotation = handlerMethod.getMethodAnnotation(Custom.class);
                if (annotation != null) {
                    return true;
                }
            }
            return false;
        }
    }

    private static class TestController {
        @Custom
        public void testMethodWithAnnotation() {}

        public void testMethodWithoutAnnotation() {}
    }

    @Test
    public void testMethodWithAnnotation() throws Exception {
        Method method = TestController.class.getMethod("testMethodWithAnnotation");
        TestController controller = new TestController();
        HandlerMethod handlerMethod = new HandlerMethod(controller, method);

        MyHandlerInterceptor interceptor = new MyHandlerInterceptor();
        boolean result = interceptor.preHandle(null, null, handlerMethod);

        assertTrue(result);
    }

    @Test
    public void testMethodWithoutAnnotation() throws Exception {
        Method method = TestController.class.getMethod("testMethodWithoutAnnotation");
        TestController controller = new TestController();
        HandlerMethod handlerMethod = new HandlerMethod(controller, method);

        MyHandlerInterceptor interceptor = new MyHandlerInterceptor();
        boolean result = interceptor.preHandle(null, null, handlerMethod);

        assertFalse(result);
    }
}

If you are using Spring (the spring-test library specifically), you can simply use ReflectionTestUtils.setField instead of Whitebox.setInternalState

EDIT 2020-09-21: Since 3.4.0, Mockito supports mocking static methods, API is still incubating and is likely to change, in particular around stubbing and verification. It requires the mockito-inline artifact. And you don't need to prepare the test or use any specific runner. All you need to do is :

@Test
public void name() {
    try (MockedStatic<LoggerFactory> integerMock = mockStatic(LoggerFactory.class)) {
        final Logger logger = mock(Logger.class);
        integerMock.when(() -> LoggerFactory.getLogger(any(Class.class))).thenReturn(logger);
        new Controller().log();
        verify(logger).warn(any());
    }
}

The two inportant aspect in this code, is that you need to scope when the static mock applies, i.e. within this try block. And you need to call the stubbing and verification api from the MockedStatic object.

@Mick, try to prepare the owner of the static field too, eg :

@PrepareForTest({GoodbyeController.class, LoggerFactory.class})

EDIT1 : I just crafted a small example. First the controller :

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Controller {
    Logger logger = LoggerFactory.getLogger(Controller.class);

    public void log() { logger.warn("yup"); }
}

Then the test :

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import static org.mockito.Matchers.any;
import static org.mockito.Matchers.anyString;
import static org.mockito.Mockito.verify;
import static org.powermock.api.mockito.PowerMockito.mock;
import static org.powermock.api.mockito.PowerMockito.mockStatic;
import static org.powermock.api.mockito.PowerMockito.when;

@RunWith(PowerMockRunner.class)
@PrepareForTest({Controller.class, LoggerFactory.class})
public class ControllerTest {

    @Test
    public void name() throws Exception {
        mockStatic(LoggerFactory.class);
        Logger logger = mock(Logger.class);
        when(LoggerFactory.getLogger(any(Class.class))).thenReturn(logger);
        
        new Controller().log();
        
        verify(logger).warn(anyString());
    }
}

Note the imports ! Noteworthy libs in the classpath : Mockito, PowerMock, JUnit, logback-core, logback-clasic, slf4j

EDIT2 : As it seems to be a popular question, I'd like to point out that if these log messages are that important and require to be tested, i.e. they are feature / business part of the system then introducing a real dependency that make clear theses logs are features would be a so much better in the whole system design, instead of relying on static code of a standard and technical classes of a logger.

For this matter I would recommend to craft something like= a Reporter class with methods such as reportIncorrectUseOfYAndZForActionX or reportProgressStartedForActionX. This would have the benefit of making the feature visible for anyone reading the code. But it will also help to achieve tests, change the implementations details of this particular feature.

Hence you wouldn't need static mocking tools like PowerMock. In my opinion static code can be fine, but as soon as the test demands to verify or to mock static behavior it is necessary to refactor and introduce clear dependencies.

Not possible through mockito. From their wiki

Why Mockito doesn't mock private methods?

Firstly, we are not dogmatic about mocking private methods. We just don't care about private methods because from the standpoint of testing private methods don't exist. Here are a couple of reasons Mockito doesn't mock private methods:

It requires hacking of classloaders that is never bullet proof and it changes the api (you must use custom test runner, annotate the class, etc.).

It is very easy to work around - just change the visibility of method from private to package-protected (or protected).

It requires me to spend time implementing & maintaining it. And it does not make sense given point #2 and a fact that it is already implemented in different tool (powermock).

Finally... Mocking private methods is a hint that there is something wrong with OO understanding. In OO you want objects (or roles) to collaborate, not methods. Forget about pascal & procedural code. Think in objects.

Update July 29, 2015 by @durron597: This excellent answer was correct in 2013, however it has since been rendered obsolete by an update to Mockito. See this answer.

I use latest JUnit with Mockito core dependency and hamcrest 1.3 in many Maven projects at work. Till now nobody reported any problem with this. So if this works for your tests go with the newest Version for all three. Just ensure to use mockito core instead of all.

So I would recommend to go with option 2 to have all benefits of the newer versions. If you are really in doubt that anything could go wrong use option 4 which is the safest one. But of course you could go with option 2 and when in the near future anything would be wrong you could switch to option 2. Or since then a newer mockito is already out there solving this.

Note from mockito Issue 397: This problem does not appear with mockito-core.

Just incase any M1 Mac users stumble onto this page like I did.

My Issue -

My spring boot project with wiremock tests, would run on my old intel mac but failed to run when I moved to my new M1 Mac.

_ _

I had 2 error messages

• java.lang.IllegalStateException: No Server ALPNProcessors!
• Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-osx-aarch_64

Fix -

I needed a property to test.application

wiremock.server.httpsPort=-1