How to use MockingMultipleInterfacesTest class of org.mockitousage.basicapi package

If possible I would try to write those test without Spring Context. If you create this class in your test without spring, then you have full control over its fields.

To set the @value field you can use Springs ReflectionTestUtils - it has a method setField to set private fields.

@see JavaDoc: ReflectionTestUtils.setField(java.lang.Object, java.lang.String, java.lang.Object)

On a first glance, the answer is simply: well, there are several mocking frameworks out there, and there are different ways to use them.

The first example tells JUnit to use the "unit test runner" that the Mockito mocking framework provides. The second example uses the unit test runner from the PowerMock framework.

In order for things to make sense, you would also have different import statements, as both frameworks have different implementations for the @Mock annotation for example.

( the main point of using these framework-specific test runners is that they take care of initializing all the fields with special framework-specific annotations ).

So: the difference here is simply that: the first example is written to use the Mockito framework, the second one uses PowerMock.

Now, which one of those to use?

Answer: Mockito.

Why? Somehow an ugly truth is: the PowerMock-one basically is a cry for help. It says "the class under test is badly designed, please fix it". Meaning: as a developer, you can write "easy to test" code, or "hard to test" code. Many people do the second: they write code that is hard to test. And then, PowerMock(ito) provides means to still test that code.

PowerMock(ito) gives you the ability to mock (thus control) calls to static methods, and to new(). To enable that, PowerMock(ito) manipulates the byte code of your code under test. That is perfectly fine for small code bases, but when you face millions of lines of production code, and thousands of unit tests, things are totally different.

I have seen many PowerMock tests fail for no apparent reason, to find out hours later ... that some "static" thing somewhere else was changed, and that somehow affect a different PowerMock static/new driven test case.

At some point, our team made a conscious decision: when you write new code, and you can only test that with PowerMock ... that isn't acceptable. Since then, we only created Mockito test cases, and not once since then we saw similar bizarre problems that bugged us with PowerMock.

The only acceptable reason to use PowerMock is when you want to test existing (maybe 3rd party) code that you do not want to modify. But of course, what is the point of testing such code? When you can't modify that code, why should tests fail all of a sudden?

With mockito v 3.4.0 we can simply use mockStatic() method without powermock library :

 try (MockedStatic mocked = mockStatic(Foo.class)) {
   mocked.when(Foo::method).thenReturn("bar");
   assertEquals("bar", Foo.method());
   mocked.verify(Foo::method);
 }

assertEquals("foo", Foo.method());

Latest documentation and example : https://javadoc.io/static/org.mockito/mockito-core/3.5.10/org/mockito/Mockito.html#static_mocks

JMockit can handle final and static. Just pay attention to how to set it up as it requires the -javaagent JVM parameter, or classpath tweaks, or extra annotations to be able to mock final and static stuffs.

Using void reset(T... mocks) will reset all stubbings on the mocks. If you just need to reset the invocation counts for subsequent verifications, use void clearInvocations(T... mocks).

I read this question and the issue carefully but not sure if I understood them clearly - From my understanding, it's correct that powermock raise the exception when you pass k and x but only verify k.

Because you are mocking the static method StaticObj.put, when you pass parameter k and x and verify it with

PowerMockito.verifyStatic(times(1));
StaticObj.put("k1", "k1");

PowerMockito.verifyStatic(times(1));
StaticObj.put("x1", "x"); 

This should work. And when you verify parameter k and x with verification for k is commented out.

// PowerMockito.verifyStatic(times(1));
// StaticObj.put("k1", "k1");

PowerMockito.verifyStatic(times(1));
StaticObj.put("x1", "x");

Powermock will get the invocation with put("k1"...) first apparently, so the verification of x will raise an error. Your verification process is sequenced.

You want to set up an Answer object that does that. Have a look at the Mockito documentation, at https://static.javadoc.io/org.mockito/mockito-core/2.8.47/org/mockito/Mockito.html#answer_stubs

You might write something like

when(mockService.doAction(any(Request.class), any(Callback.class))).thenAnswer(
    new Answer<Object>() {
        Object answer(InvocationOnMock invocation) {
            ((Callback<Response>) invocation.getArguments()[1]).reply(x);
            return null;
        }
});

(replacing x with whatever it ought to be, of course)

I found the faulty part.

I changed

@RunWith(MockitoJUnitRunner.class)

to

@RunWith(PowerMockRunner.class)

Now the mocking works. But i have to say that as Jon Skeet printed out, the enum does not have everywhere that mocked member-instance. So in another Unit test calling MyEnum.CONSTANT.sayHello(); will print again it works instead of Hello!.

I can tell from real world projects, that it works well without interfaces only having the implementing class. Following the principle "You aren't gonna need it" (YAGNI), you simplify your code if you follow that rule. Dependency Injection works also well with classes, interfaces are not a requirement for it.

Sure you can write and reuse test implementations, but you can do the same with mocks e.g. with mockito and overwrite the behavior of your implementation class for test cases.