I think

Mockito.reset(wareHouseSpy)

would do it.

I haven't tried Whitebox (which comes with Powermock), but try something like:

@RunWith(PowerMockRunner.class)
@PrepareForTest(MyClass.class)
public class MyClassTest {
    private MyClass myClass;

    @Before
    public void setup() {
        myClass = PowerMockito.spy(new MyClass());
        PowerMockito.doNothing().when(myClass, "myPrivateMethod");
    }
    //Tests..
}

.. as far as I can remember..

You cannot return anyString(), which is a matcher. It has to be a real string instance, like "foo".

I have to strongly disagree with this question.

There is no justification for a mocking tool that limits design choices. It's not just static methods that are ruled out by EasyMock, EasyMock Class Extension, jMock, Mockito, and others. These tools also prevent you from declaring classes and methods final, and that alone is a very bad thing. (If you need one authoritative source that defends the use of final for classes and methods, see the "Effective Java" book, or watch this presentation from the author.)

And "initialising collaborators rather than injecting them" often is the best design, in my experience. If you decompose a class that solves some complex problem by creating helper classes that are instantiated from that class, you can take advantage of the ability to safely pass specific data to those child objects, while at the same time hiding them from client code (which provided the full data used in the high-level operation). Exposing such helper classes in the public API violates the principle of information hiding, breaking encapsulation and increasing the complexity of client code.

The abuse of DI leads to stateless objects which really should be stateful because they will almost always operate on data that is specific to the business operation. This is not only true for non-public helper classes, but also for public "business service" classes called from UI/presentation objects. Such service classes are usually internal code (to a single business application) that is inherently not reusable and have only a few clients (often only one) because such code is by nature domain/use-case specific. In such a case (a very common one, by the way) it makes much more sense to have the UI class directly instantiate the business service class, passing data provided by the user through a constructor.

Being able to easily write unit tests for code like this is precisely what led me to create the JMockit toolkit. I wasn't thinking about legacy code, but about simplicity and economy of design. The results I achieved so far convinced me that testability really is a function of two variables: the maintainability of production code, and the limitations of the mocking tool used to test that code. So, if you remove all limitations from the mocking tool, what do you get?

I solved in this way:

@Spy Response response;

...

// for assignments in code under testing:
doReturn( response ).when( dwConnector ).getResource( anyString() );

// for entity and response status reading:
doReturn( "{a:1}".getBytes() ).when( response ).readEntity( byte[].class );
doReturn( 200 ).when( response ).getStatus();

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

From an identical issue that I just ran into, I suspect that sample is a mock, and you stubbed sample.getId() elsewhere? That caused this problem in my case, anyhow.

For some reason, Mockito gets upset if one of the arguments you pass to the stub used with doThrow in this way is the result of a method you also mocked. Perhaps it's a re-entrancy check of sorts to avoid infinite loops, I don't know.

Regardless, try replacing sample.getId() with a constant value and that should solve the issue. You could consider using a constant declared in your test for both the mock and any further uses of it. You could then also check that sample.getId() was used by the method you're testing by adding another call to verify.

Well mockito mocks works by extending the class and overriding the method, which in your case is not possible on A.a(String). If you want this to happen you have to remove the final modifier.

Now assuming A.a(String) is not final, what you ask is completely doable with mockito:

given(mockA.a(anyString()).willAnswer(returnOfB(bInstance));

Answer<String> returnOfB(final B bInstance) {
    return new Answer<String>() {
         public String answer(Invocation invocation) {
             String arg = (String) invocation.getActualArguments()[0];
             return bInstance.b(arg);
         }
    };
}

Please note this answer has been written on a phone and might have typo, or wrong names, though you should get the idea of what should be done to achieve what you want.

Cheers

You can mock without usage of the PowerMock it but in a slightly more complicated way:

KeyStoreSpi keyStoreSpiMock = mock(KeyStoreSpi.class);
KeyStore keyStoreMock = new KeyStore(keyStoreSpiMock, null, "test"){ };
keyStoreMock.load(null);  // this is important to put the internal state "initialized" to true

From now you just mock keyStoreSpiMock, for example:

when(keyStoreSpiMock.engineGetKey(any(), any())).thenReturn(mock(Key.class);