How to use getDescription method of org.mockito.junit.MockitoJUnitRunner class

I got this when combining PowerMock with Mockito. Fixed by using compatible version as shown here: https://github.com/powermock/powermock/wiki/Mockito#supported-versions

You want to set up an Answer object that does that. Have a look at the Mockito documentation, at https://static.javadoc.io/org.mockito/mockito-core/2.8.47/org/mockito/Mockito.html#answer_stubs

You might write something like

when(mockService.doAction(any(Request.class), any(Callback.class))).thenAnswer(
    new Answer<Object>() {
        Object answer(InvocationOnMock invocation) {
            ((Callback<Response>) invocation.getArguments()[1]).reply(x);
            return null;
        }
});

(replacing x with whatever it ought to be, of course)

Take a look at this reference in the official API. You want to reverse the way your call is made and adjust the argument too, since this is a void method that you expect to throw an exception.

doThrow(new ContentIOException()).when(StubbedObject).putContent(contentStream);

If you use Mockito you can use verify() to check the number of times a method was called. Use it like this:

verify(mockedObject, times(1)).methodToValidate();

You can check if methodToValidate() was called with a specific string, e.i verify(mockedObject, times(1)).methodToValidate("a specific value"); or you can use it with anyString() like this: verify(mockedObject, times(1)).methodToValidate(anyString());.

Unless this method is called with your specified paramterer, the test will fail

Read more about verify here.

UPDATE

Since your edited post states that you are using jMock, a quick googeling showed me that it is possible to achieve a similar behaviour with jMock and it's expect method. It's used as below:

mockedObject.expects(once()).method("nameOfMethod").with( eq("An optional paramter") );

More detailed explanation can be found by reading jMocks getting started page.

When involving Spring:

If you want to use Spring test framework features in your tests like for example @MockBean, then you have to use @ExtendWith(SpringExtension.class). It replaces the deprecated JUnit4 @RunWith(SpringJUnit4ClassRunner.class)

When NOT involving Spring:

If you just want to involve Mockito and don't have to involve Spring, for example, when you just want to use the @Mock / @InjectMocks annotations, then you want to use @ExtendWith(MockitoExtension.class), as it doesn't load in a bunch of unneeded Spring stuff. It replaces the deprecated JUnit4 @RunWith(MockitoJUnitRunner.class).

To answer your question:

Yes you can just use @ExtendWith(SpringExtension.class), but if you're not involving Spring test framework features in your tests, then you probably want to just use @ExtendWith(MockitoExtension.class).

Here is the solution to the above mentioned scenario. As I was not interested in testing the invocation of newTransactionTemplate.execute(), it being an spring API. I wanted to test the invocation of reserveService.callReserve(reserveDetails) and reserveService.callRelease(id). The only way to test this is if we create a transactiontemplate/transactioncallback "real" implementation/stub that is just pass thru. so the doIntransaction method should do nothing more than execute the action. then we can set expectation on the action methods which in this case is the reserveService.

    when(mockTransactionTemplate.execute(Mockito.<TransactionCallback>any())).thenAnswer(new Answer() {
         public Object answer(InvocationOnMock invocation) {
             Object[] args = invocation.getArguments();
           TransactionCallback arg = (TransactionCallback)args[0];
             return arg.doInTransaction(new SimpleTransactionStatus());
         }
     });     
    when(mockResourceService.callReserve(any(ReserveDetails.class))).thenReturn(reserveInfo);
    when(mockResourceService.callRelease(eq(id))).thenReturn(releaseInfo);

    //Call the exe method
    someService.exe();

    verify(mockResourceService, times(1)).callReserve(any(ReserveDetails.class));
    verify(mockSomeOtherService, times(1)).doSomthing());
    verify(mockMemberResourceService, times(1)).callRelease(eq(id)); 

@Spy and @InjectMocks cannot be used well together (see Google Code issue #489 and GitHub issue #169), and for what they do it is not clear or common that they should be used together at all. In well-written Mockito usage, you generally should not even want to apply them to the same object.

• @InjectMocks works as a sort of stand-in dependency injection for the system under test: If you have a test that defines a @Mock or @Spy of the right type, Mockito will initialize any fields in your @InjectMocks instance with the contents of those test fields. This might be handy if you haven't otherwise structured your system-under-test for dependency injection (or if you use a DI framework that does field injection) and you want to replace those dependencies with mocks. It can be pretty fragile—unmatched fields will be silently ignored and will remain null if not set in an initializer—but remains a decent annotation for your system under test.

• @Spy, like @Mock, is designed to set up test doubles; you should use it when you have a collaborator that you want to stub or verify. Though there are cases where you could spy on your system under test, @Spy and @Mock are meant for dependencies, and not for the functionality you are testing.

Ideally, you should not have any class that fulfills both roles in the same test, or else you may find yourself writing a test that painstakingly tests behavior that you've stubbed rather than actual production behavior. In any case it will be more difficult to tell exactly what the test covers versus the behavior you've stubbed.

Of course, this may not apply if you're trying to use Mockito to test a single method in isolation, and you want to stub calls to one method while testing the other. This can be accomplished by creating a spy of your system-under-test and mocking some of its methods to avoid calling collaborators. However, this might also be an indication that your class is violating the Single Responsibility Principle, and that you should break down the class into multiple independent classes that work together. Then, in your test, you can allow instances to have exactly one role and never need both annotations at once.

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.

You don't need MockRestServiceServer object. The annotation is @InjectMocks not @Inject. Below is an example code that should work

@RunWith(MockitoJUnitRunner.class)
public class SomeServiceTest {
    @Mock
    private RestTemplate restTemplate;

    @InjectMocks
    private SomeService underTest;

    @Test
    public void testGetObjectAList() {
        ObjectA myobjectA = new ObjectA();
        //define the entity you want the exchange to return
        ResponseEntity<List<ObjectA>> myEntity = new ResponseEntity<List<ObjectA>>(HttpStatus.ACCEPTED);
        Mockito.when(restTemplate.exchange(
            Matchers.eq("/objects/get-objectA"),
            Matchers.eq(HttpMethod.POST),
            Matchers.<HttpEntity<List<ObjectA>>>any(),
            Matchers.<ParameterizedTypeReference<List<ObjectA>>>any())
        ).thenReturn(myEntity);

        List<ObjectA> res = underTest.getListofObjectsA();
        Assert.assertEquals(myobjectA, res.get(0));
    }