How to use createMock method of org.mockito.internal.util.MockUtil class

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.

Since you are using powermock features (@PrepareForTest, PowerMockito.whenNew etc.), you have to run your test with the PowerMockRunner.

@RunWith(PowerMockRunner.class)

Because ClassB#geResult is not private, you may also simplify your code and replace

when( mockedClassB, "getResult", any(String[].class) ).thenReturn(someValue); 

by

when(mockedClassB.getResult(any(String[].class))).thenReturn(someValue);

As you noted, act is not a mock, and therefore you cannot record behavior on it. You could use Mockito.spy to, well, spy (or partially mock) the act object so that you only record the behavior of secondMethod and execute the actual code for firstMethod.

Note, however, that matchers can't be used in doReturn calls regardles of how you're mocking or spying your object. A return value must be a concrete object.

class ActivityTest() {

  Activity act;

  @Before
  public void setup(){
     act = Mockito.spy(new Activity()); // Here!
  }

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

A slightly more elegant syntax allows you to use annotations instead of explicitly calling Mockito.spy, but it's a matter of taste really:

@RunWith(MockitoJUnitRunner.class)
class ActivityTest() {

  @Spy
  Activity act = new Activity();

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

To see coverage for production code change the pattern to com.cdk.dmg.asset.

You need to Enable coverage in test folders if you want see coverage in tests (this option is disabled on your screenshot and the pattern is set to record data for tests only, hence no results).

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

It seems that this might be caused because it can't find bytebuddy installed, referring to:

Caused by: java.lang.NoSuchMethodError: net.bytebuddy.dynamic.loading.MultipleParentClassLoader$Builder.appendMostSpecific(Ljava/util/Collection;)Lnet/bytebuddy/dynamic/loading/MultipleParentClassLoader$Builder;

From what I can find online adding bytebuddy to your dependencies might fix this.

    <dependency>
      <groupId>net.bytebuddy</groupId>
      <artifactId>byte-buddy</artifactId>
      <version>XXX</version>
    </dependency>

It is because of Java/Mockito compatibility. For example, if you are using Java 11 with Mockito 2.17.0, it will throw the same error (Upgrading to Mockito 2.22.0 or later will solve it). Aside from digging into their release artifact on Github, I am yet to see a comprehensive document that spells out the compatibility matrix. Here is a helpful compatibility Matrix (based on quick test)

• Mockito * - 2.17.0 => Java 8

(footnote: * - dont know how far back)

• Mockito 2.18.0 - 3.2.4 => Java 11

The right thing to do is to restructure your code to make it more testable as shown below. Restructuring your code to remove the direct dependency on Date will allow you to inject different implementations for normal runtime and test runtime:

interface DateTime {
    Date getDate();
}

class DateTimeImpl implements DateTime {
    @Override
    public Date getDate() {
       return new Date();
    }
}

class MyClass {

    private final DateTime dateTime;
    // inject your Mock DateTime when testing other wise inject DateTimeImpl

    public MyClass(final DateTime dateTime) {
        this.dateTime = dateTime;
    }

    public long getDoubleTime(){
        return dateTime.getDate().getTime()*2;
    }
}

public class MyClassTest {
    private MyClass myClassTest;

    @Before
    public void setUp() {
        final Date date = Mockito.mock(Date.class);
        Mockito.when(date.getTime()).thenReturn(30L);

        final DateTime dt = Mockito.mock(DateTime.class);
        Mockito.when(dt.getDate()).thenReturn(date);

        myClassTest = new MyClass(dt);
    }

    @Test
    public void someTest() {
        final long doubleTime = myClassTest.getDoubleTime();
        assertEquals(60, doubleTime);
    }
}

You could capture the value, e.g.

final ArgumentCaptor<Double> captor = ArgumentCaptor.forClass(Double.class)
...
verify(myManager).method1(captor.capture());

Then assert:

assertEquals(expected, captor.getValue(), delta)

Or, perhaps, use an argument matcher which does the assertion:

verify(myManager).method1(doubleThat(new ArgumentMatcher<Double>() 
{
    @Override 
    public boolean matches(final Object actual)
    {
        return Math.abs(expected - (Double) actual) <= delta;
    }
}));

Update:

Instead of using either of the methods above, you could use AdditionalMatchers.eq(double, double) instead, e.g.:

verify(myManager).method1(AdditionalMatchers.eq(expected, delta));

Although use AdditonalMatchers matchers wisely, as per the documentation:

AdditionalMatchers provides rarely used matchers, kept only for somewhat compatibility with EasyMock. Use additional matchers very judiciously because they may impact readability of a test. It is recommended to use matchers from Matchers and keep stubbing and verification simple.