How to use DetectingMisusedMatchersTest class of org.mockitousage.misuse package

You are using the @InjectMocks for constructor incjection. This will work as long as Mockito finds the field not initalized (null). JUnit is creating a new instance of the test class before each test, so JUnit fans (like me) will never face such problem. TestNg is not creating a new instance of test class. It's keeping the state between test methods, so when MockitoAnnotations.initMocks(this) is called for the second time, Mockito will find subject field already initialized and will try to use field injection. This on the other turn will work until the field is not final.

Is this is a bug? I believe not - rather a natural consequence of the API design. Some workaround for you would be to add

this.subject = null;

in some @AfterMethod method.

Remove junit and mockito dependencies spring-boot-starter-test will provide the rights versions of these dependencies.

spring-boot-starter-test will add junit:4.12 and mockito:2.2.29

I've recently adopted a project that uses JMockit and I think the quality of the code has certainly suffered as a result of the library's ability to mock out static and private methods.

The tests are very brittle because implementation details contained in private methods are being tested (so if I change how the class does something it can break tests, even if what the class does has not been affected).

The code is also littered with calls to static methods - if the developers had not had the ability to mock these out then I think they would have made more effort to de-couple things a little better.

Mockito cannot mock static method. Your when check is not valid:

  when(BasketHelper.getAction(request)).thenReturn(0);
  when(BasketHelper.getActionProduct(site, request)).thenReturn(product);

That is another reason why we want to reduce the use of static method as it is hard to mock.

There is no easier way to mock the behavior if your class stays like this. However if you want to change your design and make both methods non-static. The correct way of using "when" is to apply the check on mocked object. For example:

  BasketHelper basketHelper = mock(BasketHelper.class);
  when(basketHelper.getAction(request)).thenReturn(0);
  when(basketHelper.getActionProduct(site, request)).thenReturn(product);

But once again, this only work if you re-designed your class's getAction and getProduct method to be NON-STATIC.

I remember there are some other testing framework that does support mocking static method.

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()

Use a Hamcrest matcher, as shown in the documentation:

when(carFinderMock.find(argThat(isRed()))).thenReturn(car1);

where isRed() is defined as

private Matcher<MappingFilter> isRed() {
    return new BaseMatcher<MappingFilter>() {
        // TODO implement abstract methods. matches() should check that the filter is RED.
    }
}

This should work

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.verify;

verify(bar).DoStuff(any(Foo[].class));

The reason is that the spring configuration for the test having the @MockBean is different from the rest of the tests, so the spring framework cannot cache previously used context and needs to load it again. Here you can find a more detailed explanation: https://github.com/spring-projects/spring-boot/issues/10015

As you said, if you move the mock bean to the parent class the context doesn't get reloaded, which makes sense as the bean configuration remains the same.

A possible workaround is defining your mock bean as a simple mock and injecting it manually where is required.

For instance, UserController has a dependency on Foo:

public class UserControllerTest extends BaseITCase {

    private Foo foo = Mockito.mock(Foo.class);

    @Autowired
    private UserController userController;

    @Before
    public void setUp() {
        super.setup();

        this.userController.setFoo(foo);
    }
}

@Component
public class UserController {

    private Foo foo;

    @Autowired
    public void setFoo(final Foo foo) {
        this.foo = foo;
    }
}

Hope this helps.

They both achieve the same result. Using an annotation (@Mock) is usually considered "cleaner", as you don't fill up your code with boilerplate assignments that all look the same.

Note that in order to use the @Mock annotation, your test class should be annotated with @RunWith(MockitoJUnitRunner.class) or contain a call to MockitoAnnotations.initMocks(this) in its @Before method.