How to use getSomething method of org.mockitousage.bugs.deepstubs.DeepStubsWronglyReportsSerializationProblemsTest class

I believe that what is really happening here is more than one mock method invocation in single when(...).then(...) statement.

Consider following example:

when(program.getName()).thenReturn(String.valueOf(program.compareTo(null)));

It returns the same exception that You have. It is because there are two methods invoked on mock: getName() and compareTo() in single when(...).thenReturn(...) statement.

Also in this page (the mockito documentation) You can read that:

By default, for all methods that return value, mock returns null, an empty collection or appropriate primitive/primitive wrapper value (e.g: 0, false, ... for int/Integer, boolean/Boolean, ...).

Therefore mockito has to have some mechanism for detecting what to do (return) for which invocation on some mocked object.

In Your example second invocation is made by new TreeSet<>(Collections.singleton(program)) statement, because TreeSet constructor is using compareTo() method of Your mock.

It seems that implementation of TreeSet changed from java 6 to java 7. That is why it could have worked earlier.

Caused by: org.mockito.exceptions.base.MockitoException: Checked exception is invalid for this method! Invalid: java.net.ConnectException: Test exception

As stated by the exception message (and told in comments), you have to throw a RestClientException, not a ConnectException:

Mockito.when(restOperations.exchange(
        Mockito.anyString(), Mockito.<HttpMethod>any(), Mockito.<HttpEntity<?>>any(),
        Mockito.<Class<UserByRoleHolder>>any())).thenThrow(new RestClientException("Test exception"));

You get this error message, because the method exchange declares no thrown exception and ConnectException is a checked exception (i.e. must be declared when thrown).

With mockito v 3.4.0 we can simply use mockStatic() method without powermock library :

 try (MockedStatic mocked = mockStatic(Foo.class)) {
   mocked.when(Foo::method).thenReturn("bar");
   assertEquals("bar", Foo.method());
   mocked.verify(Foo::method);
 }

assertEquals("foo", Foo.method());

Latest documentation and example : https://javadoc.io/static/org.mockito/mockito-core/3.5.10/org/mockito/Mockito.html#static_mocks

Let me quote the official documentation:

Important gotcha on spying real objects!

Sometimes it's impossible to use when(Object) for stubbing spies. Example:

List list = new LinkedList();
List spy = spy(list);

// Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");

// You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

In your case it goes something like:

doReturn(resultsIWant).when(myClassSpy).method1();

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.

You can chain doReturn() calls before when(), so this works (mockito 1.9.5):

private static class Meh
{
    public String meh() { return "meh"; }
}

@Test
public void testMeh()
{
    final Meh meh = spy(new Meh());

    doReturn("foo").doReturn("bar").doCallRealMethod().when(meh).meh();

    assertEquals("foo", meh.meh());
    assertEquals("bar", meh.meh());
    assertEquals("meh", meh.meh());
}

Also, I didn't know you could do when(x.y()).thenReturn(z1,z2), when I have to do this I use chained .thenReturn() calls as well:

when(x.y()).thenReturn(z1).thenThrow().thenReturn(z2)

You can change the System.in stream using System.setIn() method.

Try this,

@Test
public void shouldTakeUserInput() {
    InputOutput inputOutput= new InputOutput();

    String input = "add 5";
    InputStream in = new ByteArrayInputStream(input.getBytes());
    System.setIn(in);

    assertEquals("add 5", inputOutput.getInput());
}

You have just modified the System.in field. System.in is basically an InputStream which reads from the console (hence your input in the console). But you just modified it and let the system to read from the provided inputstream instead. So it wont read from console anymore but from the inputstream provided.

Actually they are technically the same. When Mockito was first created, we were talking about stubs, so the vocabulary followed that idea. Later people thought it was better to think in interactions rather that technical terms, so the vocabulary followed the when ... then ... style. This change in vocabulary helps people to think about interactions, messaging between object. Which is the most interesting idea (message passing) thing in an object oriented language (quoting Alan Kay).

Nowadays testing approach has evolved to Behavior Driven Development (from Dan North), which is almost the same thing but focus even more on the behavior at design time. To reflect that thinking, people asked Mockito to offer an API that reflect that change. So you also use given ... will ... style from BDDMockito

given(the_type.performs_that()).willReturn(something)

This is my preferred vocabulary now as I use tests to drive my objects design.

PropertyDescriptor#getPropertyType() returns an object of Class<?>, where the ? means "this is a type, but I don't know what it is". Let's call this type "X". So when(mockDescriptor.getPropertyType()) creates an OngoingStubbing<Class<X>>, whose method thenReturn(Class<X>) can only accept objects of Class<X>. But the compiler doesn't know what type this "X" is, so it will complain about you passing in a Class of any type. I think this is the same reason the compiler complains about calling add(...) on a Collection<?>.

When you explicitly specify Class<?> for the type on the when method, you're not saying that mockDescriptor.getPropertyType() returns a Class<?>, you're saying that when returns an OngoingStubbing<Class<?>>. Then, the compiler checks to make sure whatever you're passing into when is of a type that matches Class<?>; since getPropertyType() returns the "Class<X>" I mentioned earlier, it of course matches the Class<?> you specified.

So basically

// the inferred type is Class<"some type">
Mockito.when(mockDescriptor.getPropertyType())

// the specified type is Class<"any type">
Mockito.<Class<?>>when(mockDescriptor.getPropertyType())

In my IDE, the error message for your original code is

The method thenReturn(Class<capture#1-of ?>) in the type OngoingStubbing<Class<capture#1-of ?>> is not applicable for the arguments (Class<String>)

That capture#1-of ? is the "X" I described above.