What are you looking for is called partial mocking.

In PowerMock you can use mockStaticPartial method.

In PowerMockito you can use stubbing, which will stub only the method defined and leave other unchanged:

PowerMockito.stub(PowerMockito.method(StaticUtilClass.class, "someStaticMethod")).toReturn(5);

also don't forget about the

@PrepareForTest(StaticUtilClass.class)

JUnit and TestNG are the main unit test frameworks.

Comparison can be found here - http://www.mkyong.com/unittest/junit-4-vs-testng-comparison

I've used JUnit in most places I've worked, it seems to be the standard, but there are some nice things in TestNG.

I've used the following in combination with JUnit to facilitate testing:

• Mockito for mocking objects - http://code.google.com/p/mockito/
• Hamcrest assertions for more readable assertions - http://code.google.com/p/hamcrest/
• Twip for parameterized testing, the JUnit stuff isn't the greatest, in fact TestNG does this better as well - http://twip.sourceforge.net/

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.

Mockito itself doesn't seem to be able to mock native methods according to this Google Group thread. However you do have two options:

1. Wrap the TableElement class in an interface and mock that interface to properly test that your SUT calls the wrapped insertRow(...) method. The drawback is the extra interface that you need to add (when GWT project should've done this in their own API) and the overhead to use it. The code for the interface and the concrete implementation would look like this:

   // the mockable interface
   public interface ITableElementWrapper {
       public void insertRow(int index);
   }
   
   // the concrete implementation that you'll be using
   public class TableElementWrapper implements ITableElementWrapper {
       TableElement wrapped;
   
       public TableElementWrapper(TableElement te) {
           this.wrapped = te;
       }
   
       public void insertRow(int index) {
           wrapped.insertRow(index);
       }
   }
   
   // the factory that your SUT should be injected with and be 
   // using to wrap the table element with
   public interface IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te);
   }
   
   public class GwtWrapperFactory implements IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te) {
           return new TableElementWrapper(te);
       }
   }
   

2. Use Powermock and it's Mockito API extension called PowerMockito to mock the native method. The drawback is that you have another dependency to load into your test project (I'm aware this may be a problem with some organizations where a 3rd party library has to be audited first in order to be used).

Personally I'd go with option 2, as GWT project is not likely to wrap their own classes in interfaces (and it is more likely they have more native methods that needs to be mocked) and doing it for yourself to only wrap a native method call is just waste of your time.

I wanted to do the same thing, and eventually accomplished it by using the Mockito "spy" function, which wraps a real object with a mock object. All calls to the mock object get forwarded to the real object, except those you are trying to mock. For example:

ObjectMapper om = Mockito.spy(new ObjectMapper());
Mockito.when( om.writeValueAsString(ErrorObject.class)).thenThrow(new JsonProcessingException("") {});

All usages of om will be handled by the underlying ObjectMapper instance until an instance of ErrorObject gets passed in, at which point the JsonProcessingException will be thrown.

The newJsonProcessingException is created as an anonymous class, as it is a protected class and only a sub-class can be instantiated.

Static methods aren't related to any object - your helper.fetchUsernameFromInternet(...) is the same (but a bit confusing) as HelperUtils.fetchUsernameFromInternet(...) - you should even get a compiler warning due to this helper.fetchUsernameFromInternet.

What's more, instead of Mockito.mock to mock static methods you have to use: @RunWith(...), @PrepareForTest(...) and then PowerMockito.mockStatic(...) - complete example is here: PowerMockito mock single static method and return object

In other words - mocking static methods (and also constructors) is a bit tricky. Better solution is:

• if you can change HelperUtils, make that method non-static and now you can mock HelperUtils with the usual Mockito.mock

• if you can't change HelperUtils, create a wrapper class which delegates to the original HelperUtils, but doesn't have static methods, and then also use usual Mockito.mock (this idea is sometimes called "don't mock types you don't own")

I think you do need to cast it, but it shouldn't be too bad:

Foo<Bar> mockFoo = (Foo<Bar>) mock(Foo.class);
when(mockFoo.getValue()).thenReturn(new Bar());

The thenReturn() method signature is

thenReturn(T value, T... values)

So it takes an instance of T, followed by a vararg T..., which is syntactic sugar for an array. So you can use

when(foo.bar()).thenReturn(list.get(0), 
                           list.subList(1, list.size()).toArray(new Foo[]{}));

But a cleaner solution would be to create an Answer implementation that takes a List as argument and answers the next element of the list every time it's used. And then use

when(foo.bar()).thenAnswer(new SequenceAnswer<>(list));

For example:

private static class SequenceAnswer<T> implements Answer<T> {

    private Iterator<T> resultIterator;

    // the last element is always returned once the iterator is exhausted, as with thenReturn()
    private T last;

    public SequenceAnswer(List<T> results) {
        this.resultIterator = results.iterator();
        this.last = results.get(results.size() - 1);
    }

    @Override
    public T answer(InvocationOnMock invocation) throws Throwable {
        if (resultIterator.hasNext()) {
            return resultIterator.next();
        }
        return last;
    }
}

Your brackets are in the wrong place, try this:

doNothing().when(mockRegistrationPeristImpl).create(any(Registration.class));