How to use getTheField method of org.mockito.internal.util.reflection.BeanPropertySetterTest class

Use one, or more, ArgumentCaptors.

It is unclear what your types are here, but anyway. Let's suppose you have a mock which has a method doSomething() taking a Foo as an argument, then you do this:

final ArgumentCaptor<Foo> captor = ArgumentCaptor.forClass(Foo.class);

verify(mock).doSomething(captor.capture());

final Foo argument = captor.getValue();

// Test the argument

Also, it looks like your method returns void and you don't want it to do anything. Just write this:

doNothing().when(theMock).doSomething(any());

I could make your unit test pass by modifying 2 things in your code:

1. Mock mockServerSocket.accept() properly

Up to now, you mock mockServerSocket.accept() too early because mockTestClientSocket has not yet been set so it will return null, you need to set it first so your code should rather be:

mockServerSocket = mock(ServerSocket.class);
// Set it first
mockTestClientSocket = mock(Socket.class);

try {
    // Then mock it
    when(mockServerSocket.accept()).thenReturn(mockTestClientSocket);
} catch (IOException e) {
    fail(e.getMessage());
}
...

2. Synchronize your threads properly

As you launch a dedicated thread to manage your client socket, you need to synchronize your threads in order to make sure that your message will be ready to be read.

To do this you could:

1. Simplify your code by calling reader.readLine() but it is a blocking approach since your current thread will wait as long as it is needed for the other thread to write the line (the message here).

The code could be:

BufferedReader reader = ...

String receivedMessage = reader.readLine();
assertEquals("Hello, world!", receivedMessage);
mockTestClientSocket.close();
connection.closeSocket();

2. Set a value for TIMEOUT_TIME big enough even exaggeratedly big to make sure that the other thread will be ready, so for example as it is a value in nanoseconds, you could set it to 30 seconds so to 30_000_000_000L. If you don't set a value big enough, your test could be unstable in slow and/or overloaded and/or shared system such as server used for continuous integration.

You can enable verbose logging on your Mocked objects:

    import org.mockito.Mockito.mock;
    import org.mockito.Mockito.withSettings;

    List mockWithLogger = mock(List.class, withSettings().verboseLogging());

This should give you more information to understand the interactions.

https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/MockSettings.html#verboseLogging()

I believe the output from above is I null {} because @InjectMocks field injection cannot correctly resolve the types since they are both of type Map. Is this correct?

Yes, correct on these field Mockito cannot clear the ambiguity, so it simply ignores these ambiguous fields.

With a very simple Mockito run JUnit test and class I am seeing different output when the test is run with Java 1.6.0_32 and Java 1.7.0_04 and want to understand why this is happening.

Actually the diferrence resides in a different behavior of Arrays.sort and hence Collections.sort() between JDK 6 and JDK 7. The difference resides in the new algorythm that should perform 20% less swaps. That's probably this swap operation that made things work under JDK6 and JDK7.

If I may you are "looking for trouble" if you rename only one mock field of the fields that have the same type (or same erasure). When mocks cannot be differentiated by type you really should name all your mock field to corresponding field, but the Javadoc does not state that clearly.

Thanks a lot for reporting that odd behavior by the way, I created an issue on Mockito, however for now I won't really solve this issue, but rather ensure the same behavior across JDKs. Solving this situation might need to code a new algorythm while maintaining compatibility, in the mean time you should name all your field mocks accordingly to the fields of tested class.

For now the thing to do will probably be tweaking the comparator with additional comparisons to enforce the same order on JDK6 and JDK7. Plus adding some warning in the Javadoc.

EDIT : Making two passes might solve the problem for most people.

Hope that helps. Thx for spotting the issue.

Also by the way you need either MockitoAnnotations.initMocks(this); or the runner @RunWith(MockitoJUnitRunner.class), using both is not necessary, and might even cause some problems. :)

Here is a solution that will work for you particular case:

First of all you need to create a PersonMixin since you cannot add the required annotations to the mock.

import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.JsonProperty;


@JsonAutoDetect(getterVisibility = JsonAutoDetect.Visibility.NONE, isGetterVisibility = JsonAutoDetect.Visibility.NONE)
public interface PersonMixin {

    @JsonProperty
    String getName();

    @JsonProperty
    Integer getAge();
}

Now, use the object mapper like the in following code and you will get the same result as when you serialize the real object:

Person mockPerson = mock(Person.class);
when(mockPerson.getName()).thenReturn(name);
when(mockPerson.getAge()).thenReturn(age);
objectMapper.addMixInAnnotations(Person.class, PersonMixin.class);
try {
    System.out.println(objectMapper.writeValueAsString(mockPerson));
} catch (JsonProcessingException e) {
    e.printStackTrace();
    System.err.println("Failed to serialize mock object.");
}

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

Nutshell: Can't always use when to stub spies; use doReturn.

Assuming static imports of spy and doReturn (both PowerMockito):

@RunWith(PowerMockRunner.class)
@PrepareForTest(B.class)
public class BTest {
    @Test public void testClass() throws Exception {
        B b = spy(new B());
        doReturn(42).when(b, "m");
        b.asd();
    }
}

You could also @PrepareForTest(A.class) and set up the doReturn on when(a, "m"). Which makes more sense depends on the actual test.

The thenReturn method will always return what is passed to it. The code new Servicemock() is being executed prior to the call to thenReturn. The created ServiceMock is then being passed to thenReturn. Therefore thenReturn has a absolute instance of ServiceMock not a creation mechanism.

If you need to provide an new instance, use thenAnswer

when(mockedMergeContext.createNewEntityOfType(IService.class))
  .thenAnswer(new Answer<IService>() {
     public IService answer(InvocationOnMock invocation) {
        return new ServiceMock();
     }
   });

import org.springframework.test.util.ReflectionTestUtils;

@RunWith(MockitoJUnitRunner.class)
public CustomServiceTest{

@InjectMocks
private CustomServiceImpl customService;

@Mock
private DataService dataService;

@Before
public void setup() {
    ReflectionTestUtils.setField(customService, "url", "http://someurl");
}    
...
}