How to use testname method of org.mockito.internal.matchers.apachecommons.EqualsBuilderTest class

As of Java 11, WildFly 14+ and Mockito 2.23.0+, adding jdk.unsupported module dependency to your WAR solves the problem. You can do this in two ways:

A. META-INF/MANIFEST.MF

Add the following line to META_INF/MANIFEST.MF of your WAR archive:

Dependencies: jdk.unsupported

Note that the file must end with a new line or carriage return.

Here is how you'd typically do it with ShrinkWrap/Arquillian:

@Deployment
public static WebArchive createDeployment() {
    return ShrinkWrap.create(WebArchive.class, "my-app.war")
        .addPackages(true, Mockito.class.getPackage(), Objenesis.class.getPackage(), ByteBuddy.class.getPackage())
        .addAsManifestResource(new StringAsset("Dependencies: jdk.unsupported\n" /* required by Mockito */), "MANIFEST.MF");
}

B. WEB-INF/jboss-deployment-structure.xml

Add the following content to WEB-INF/jboss-deployment-structure.xml of your WAR archive:

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="jdk.unsupported" />
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Just point that with Mockito you can also use AdditionalMatchers and ArgumentMatchers

import static org.mockito.AdditionalMatchers.not;
import static org.mockito.ArgumentMatchers.eq;

//anything but not "ejb"    
mock.someMethod(not(eq("ejb")));

According its documentation:

Example of using logical and(), not(), or() matchers:

//anything but not "ejb"
mock.someMethod(not(eq("ejb")));

There is more info in this other SO question

Hope it helps

From the PowerMock Private Method Example:

@RunWith(PowerMockRunner.class)
// We prepare PartialMockClass for test because it's final or we need to mock private or static methods
@PrepareForTest(PartialMockClass.class)
public class YourTestCase {
@Test
public void privatePartialMockingWithPowerMock() {        
    PartialMockClass classUnderTest = PowerMockito.spy(new PartialMockClass());

    // use PowerMockito to set up your expectation
    PowerMockito.doReturn(value).when(classUnderTest, "methodToMock", "parameter1");

    // execute your test
    classUnderTest.execute();

    // Use PowerMockito.verify() to verify result
    PowerMockito.verifyPrivate(classUnderTest, times(2)).invoke("methodToMock", "parameter1");
}

So to apply this to your code, I think it might become:

@RunWith(PowerMockRunner.class)
@PrepareForTest(CodeWithPrivateMethod.class)
public class PowerMock_Test {
    @Test(expected = RuntimeException.class)
    public void when_gambling_is_true_then_always_explode() throws Exception {
        CodeWithPrivateMethod spy = PowerMockito.spy(new CodeWithPrivateMethod());

        PowerMockito.doReturn(true).when(spy, "doTheGamble", anyString(), anyInt());


/* 1 */ PowerMockito.verifyPrivate(spy, times(0)).invoke("doTheGamble", anyString(), anyInt());            
        spy.meaningfulPublicApi();
/* 2 */ PowerMockito.verifyPrivate(spy, times(2)).invoke("doTheGamble", anyString(), anyInt());            
    }
}

I just coded that in the editor here. No tests have actually been run, and no bugs have been harmed in the crafting of this code.

(This pretty much helped me figure it out)

Pretty simple solution (I almost had it right to begin with): I was missing a few PowerMockito dependency jars (from https://code.google.com/p/powermock/wiki/Downloads?tm=2): Specifically {cglib-nodep-2.2.2.jar, javssist-3.18.1-GA.jar, objenesis-2.1.jar}.

It was a simple solution and kinda dumb mistake to begin with in the 1st place, since that powerMock googleCode download page has all of them: At 1st, when I had the problem, I had only downloaded and added powermock-mockito-1.5.4-full.jar; I already had the JUnit & Mockito jars, so I think that set of 3 let me write PowerMock code without any compile errors in Eclipse. The googlecode download page has the powermockito jar + dependecies in a zip, but also said powerockito jar available alone too. That situation made it kinda hard to realize I was missing some others since it appeared I had all I need from that perspective (thought I already had the dependencies I needed per my existing JUnit and Mockito jars).

In actuality, the zip with dependencies had the additional ones I needed to solve the problem. I should have double-checked that 1st, but didn't realize I made the opposite bad assumption.

So... answer is to make sure to get the zip with all dependencies [and add them all to your buildpath]. Kinda obvious and dumb in my part in the end, but hey, a lot of software bugs and problems end up being that: Simple bad assumptions or overlooked details we don't realize we made, and therefore take a while to realize when troubleshooting...

You need to provide a way of accessing the member variables so you can pass in a mock (the most common ways would be a setter method or a constructor which takes a parameter).

If your code doesn't provide a way of doing this, it's incorrectly factored for TDD (Test Driven Development).

Yes. You've misused verify. The argument to verify has to be the mock itself. Then you call the method you want to verify on the value that's returned by verify. So in this case, the first verify call should be

Mockito.verify(_client).resource(_baseUrl + "token");

and similarly for the other verify calls.

If I understand what you want to do correctly, you should be able to use andAnswer():

mockObject.someMethod(eq(param1), eq(param2));
expectLastCall().andAnswer(new IAnswer() {
    public Object answer() {
        //supply your mock implementation here...
        SomeClass arg1 = (SomeClass) getCurrentArguments()[0];
        AnotherClass arg2 = (AnotherClass) getCurrentArguments()[1];
        arg1.doSomething(blah);
        //return the value to be returned by the method (null for void)
        return null;
    }
});

The EasyMock User Guide explains:

Creating Return Values or Exceptions

Sometimes we would like our mock object to return a value or throw an exception that is created at the time of the actual call. Since EasyMock 2.2, the object returned by expectLastCall() and expect(T value) provides the method andAnswer(IAnswer answer) which allows [you] to specify an implementation of the interface IAnswer that is used to create the return value or exception.

Inside an IAnswer callback, the arguments passed to the mock call are available via EasyMock.getCurrentArguments(). If you use these, refactorings like reordering parameters may break your tests. You have been warned.

If you use the MockitoJUnitRunner to run your test, then an ArgumentCaptor will be created for you, and there's no need to initialise it explicitly. If you do that, then you can also use the @Mock annotation to create your mock objects, that is, you don't need the mock static method any more. Your test class would then begin like this.

@RunWith(MockitoJUnitRunner.class)
public class WidgetStatusServletTest {

    @Captor private ArgumentCaptor<ArrayList<WidgetStatus>> captor;
    @Mock private DBController mockController;
    @Mock private HttpServletRequest mockRequest;
    @Mock private HttpServletResponse mockResponse;
    @Mock private Repository mockRepository;

This question addresses the issue of whether to use MockitoJUnitRunner, or an explicit call to MockitoAnnotations.initMocks.

Just a side note - your test methods will be much easier to read if you use variable names that clearly indicate that your objects are mocks, like I've done here. Otherwise, in a long test class with many different variables, it's easy to lose track of which variables reference mocks, and which reference "real" objects.

I have two critiques to that approach... and please bear in mind that my knowledge of your context is almost nil, which means that what I suggest here might not work for you.

I've only once experienced a problem like the one you mentioned, and it was a symptom that there was too much coupling between the objects because the responsbilities were way to broad. Since then I use a Domain-Driven Design approach and I haven't had this problem again.

I prefer to use Test-Data Builders to create test data. This approach allows me to have a template of what I want to build, and just replace the bits I'm interested in the test. If you decide to go this way, I strongly suggest you to use a tiny library called Make-It-Easy that simplifies the creation of these builders.

And two suggestions

If you have some time, I suggest you to

1. Watch a presetation called The Deep Synergy Between Testability and Good Design by Michael Feathers - Part of the talk is about something very similar to what you're experiencing.
2. Read the book Growing Object-Orieted Systems, Guided by Tests (aka GOOS), it has all sorts of insights about how to write simple, amazing, testable code.