How to use shouldFilterStacktraceWhenInOrderThrowsMockitoException method of org.mockitousage.stacktrace.PointingStackTraceToActualInvocationTest class

User Matcher documentation isA() method.

public static <T> T isA(java.lang.Class<T> clazz)

That will solve your problem.

verify(foo).putObject(isA(SomeClass.class));

From the Mockito documentation :

Resetting mocks (Since 1.8.0)

Smart Mockito users hardly use this feature because they know it could be a sign of poor tests. Normally, you don't need to reset your mocks, just create new mocks for each test method. Instead of reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests. First potential code smell is reset() in the middle of the test method. This probably means you're testing too much. Follow the whisper of your test methods: "Please keep us small & focused on single behavior". There are several threads about it on mockito mailing list.

The only reason we added reset() method is to make it possible to work with container-injected mocks.

You should probably just recreate the spy in a @BeforeMethod :

public class Program {

    private TestObject testObject = new TestObject();
    private TestObject spyTestObject;

    @BeforeMethod
    public void buildSpy() {
        spyTestObject = spy(testObject);
    }

    @Test
    public void test1() {
       spyTestObject.makeSth(); 
       verify(spyTestObject , only()).someMethodNeedToBeChecked(); 
    }

    @Test
    public void test2() {
        // Some different scenario
       spyTestObject.makeSth(); 
       verify(spyTestObject , only()).someMethodNeedToBeChecked(); 
        ...
    }
}

Lenient mocks are what you want, if you can't just use a real UserKeychain.

Mockito.lenient().when(userKeychain.getUserStatus()).thenReturn(UserState.OK);
Mockito.lenient().when(otherUserKeychain.getUserStatus()).thenReturn(UserState.SUSPENDED);

Mockito is designed to replace systems where you can't use the real system in your test, particularly in systems that predictably invoke services instead of getting properties from data objects (or other idempotent actions). Because your system doesn't call those methods in a deterministic order, and because the calls aren't expensive and don't have side effects, I would recommend just going with the "lenient" option.

Imagine this case instead, where you are testing deleting user 1001:

when(userRpc.deleteUser(1001)).thenReturn(RPC_SUCCESS);
when(userRpc.deleteUser(1002)).thenReturn(RPC_SUCCESS);  // unnecessary

The test might pass if you ever delete the wrong user: Over-stubbing has masked a problem. Compare with this:

when(userRpc.fetchExpensiveUserDetails(1001)).thenReturn(user1001);
when(userRpc.fetchExpensiveUserDetails(1002)).thenReturn(user1002);  // unnecessary

Depending on what you're testing, this might be dangerous, but might not be so bad. Simulating a slow mobile network or with expensive data, maybe it is entirely against spec for you to fetch too much. However, in other cases, it may be acceptable. Finally, compare this case:

when(calculationResult.getRealComponent()).thenReturn(-1d);
when(calculationResult.getComplexComponent()).thenReturn(5);
when(calculationResult.getShortString()).thenReturn("-1 + 5i");

calculationResult looks an awful lot like a data object, and it is probably not a critical part of your test which of your methods to call or whether you're calling all of them. This is a case where Mockito's strict stubbing hinders you rather than helping you, and might be a case where you want to make some of those stubbings lenient. You might also choose to make the entire mock lenient, which particularly makes sense if you were to create a test helper method like stubCalculationResult(-1, 5) that prepared an entire object for you like that.

The only option better than that is to use a real object. In my example, if CalculationResult is an existing well-defined object, it may be lower risk overall to use a real one than to mock the behavior you believe at test-writing time to be correct. Similarly for your case, if you have access to a UserKeychain constructor that populates UserStatus etc, then it may be safer to use that in a test.

Though this might appear at first glance to be a slippery slope into turning a unit test into an integration test, I'd like to clarify that I'm recommending this only for data objects, which have no dependencies, and which ideally are immutable objects that have no methods with side-effects. If you use dependency injection, these are the type of single-implementation data holders that you would call new on rather than getting from your graph. This is also a good reason to separate your data objects so they are immutable and easy to construct, and to shift your services to consume those objects rather than giving methods to the data objects (favoring loginService.login(user) rather than user.login(loginService)).

You don't normally set properties on your mocked objects; instead, you do some specific thing when it's invoked.

when(slingHttpRequest.getAttribute("search")).thenReturn(someObject);

In the end, this is all about wording.

When you think of "correct" in its very fundamental sense, as in correctness, then the answer is simply: no.

You see, the goal of an integration test is to ensure that your integrated system (consisting of multiple, different components) functions as expected. The purpose of an integration test is to verify that your "plumbing" of components works as expected. Therefore: you can't verify that your system works when parts of that system are mocked out.

But then, you can think "correctness" less strictly.

Example: companies selling cars have to test ECUs. Basically a piece of hardware, running a potentially huge software stack. These ECUs normally operate within cars. So when you want to integration test an ECU, you would have to put the ECU into a car for testing, right? A car that probably doesn't exist yet. The solution here: there are hardware emulators. You plug the ECU into that emulator, and the ECU "thinks" that sits inside a real car.

So: there are good arguments to claim "a true integration test can't use mocking", but at the same time, in the real world, such "mocking" happens all the time.

The real answer is therefore: it depends on context. Therefore there isn't a universal answer. Instead, this is about communication. You "simply" have to ensure that all people in your group/org have the same understanding of such terms.

The term itself can be interpreted in different ways. You (jointly!) pick that definition that best fits your needs, to then make sure all people contributing to your project share that view (or at least know about it).

it is because of the version conflict between PowerMockito and Mockito artifacts. "MockCreationSettings.isUsingConstructor" method is removed in new versions, so you need to be sure you are using correct versions. e.g use PowerMockito version 1.6.2 with Mockito version 1.10.19 (this version has that missing method)

You can either use doNothing or doThrow on your mock to mock the behaviour of your mock.

Mockito.doNothing().when(employeeDAO).delete(any());

or

Mockito.doThrow(new RuntimeException()).when(employeeDAO).delete(any());

However, doNothing is not actually needed as this would be the default behaviour for a mock function with a void return type. You may want however to verify that this method was called. For example:

verify(employeeDAO).delete(any());

I don't want to add a Clock argument to the method because the real code shouldn't be concerned with passing in a clock.

No... but you might want to consider it as a constructor parameter. Basically you're saying that your class needs a clock with which to work... so that's a dependency. Treat it as you would any other dependency, and inject it either in a constructor or via a method. (I personally favour constructor injection, but YMMV.)

As soon as you stop thinking of it as something you can easily construct yourself, and start thinking of it as "just another dependency" then you can use familiar techniques. (I'm assuming you're comfortable with dependency injection in general, admittedly.)

Just to complete the picture:

The latest version of Mockito 2 very well supports mocking of final classes. But you have to explicitly enable this new experimental feature first!

( see here on how to do that - it boils down to add a file mockito-extensions/org.mockito.plugins.MockMaker to your classpath, containing the value mock-maker-inline )

But of course: you only mock something if you have to. Your desire to mock Enum instances is most likely driven by either not understanding that - or because you created hard to test code here. In that sense the real answer would be to look into ways that avoid this kind of mocking in the first place.