The error message you are getting is expected since you are using argument matcher for only one argument and not the other. From Matchers Javadoc:

If you are using argument matchers, all arguments have to be provided by matchers.

Therefore, the fix is to use a matcher for the second parameter of the method as well. In this case, it would be a matcher matching null. Depending on the version of Mockito and Java, you can have:

• Starting with Mockito 2, you can use ArgumentMatchers.isNull(). This works with Java 8 and above:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), isNull());
  

  Note that if you're running with Java 7 or older, you'll need an explicit cast to make this work, because the type inference in those versions of Java does not take into account the types of the method called:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), (String) isNull());
  

• If you're using Mockito 1, you can use the Matchers.isNull(clazz) instead:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), isNull(String.class));
  

For the Java ≤ 7 or Mockito 1 cases, the examples uses a case where the second parameter was of type String: it would need to be replaced with the actual type of the method parameter.

There is more than one possible argument matcher and one is eq, which is mentioned in the exception message. Use:

verify(function, times(1)).doSomething(eq(arg1), any(Argument2.class));

(static imports supposed to be there -- eq() is Matchers.eq()).

You also have same() (which does reference equality, ie ==), and more generally you can write your own matchers.

You simply inject it with the @Context annotation, as a field or method parameter.

@Path("resource")
public class Resource {
    @Context
    UriInfo uriInfo;

    public Response doSomthing(@Context UriInfo uriInfo) {

    }
}

Other than your resource classes, it can also be injected into other providers, like ContainerRequestContext, ContextResolver, MessageBodyReader etc.

EDIT

Actually I want to write a junit test for a function similar to your doSomthing() function.

I didn't pick that up in your post. But a couple options I can think of for unit tests

1. Simply create a stub, implementing only the methods you use.

2. Use a Mocking framework like Mockito, and mock the UriInfo. Example

   @Path("test")
   public class TestResource { 
       public String doSomthing(@Context UriInfo uriInfo){
           return uriInfo.getAbsolutePath().toString();
       }
   }
   [...]
   @Test
   public void doTest() {
       UriInfo uriInfo = Mockito.mock(UriInfo.class);
       Mockito.when(uriInfo.getAbsolutePath())
           .thenReturn(URI.create("http://localhost:8080/test"));
       TestResource resource = new TestResource();
       String response = resource.doSomthing(uriInfo);
       Assert.assertEquals("http://localhost:8080/test", response);
   }
   

   You'll need to add this dependency

   <dependency>
       <groupId>org.mockito</groupId>
       <artifactId>mockito-all</artifactId>
       <version>1.9.0</version>
   </dependency>
   

If you want to do an integration test, where the actual UriInfo is injected, you should look into Jersey Test Framework

Here's a complete example with the Jersey Test Framework

public class ResourceTest extends JerseyTest {

    @Path("test")
    public static class TestResource {
        @GET
        public Response doSomthing(@Context UriInfo uriInfo) {
            return Response.ok(uriInfo.getAbsolutePath().toString()).build();
        }
    }

    @Override
    public Application configure() {
        return new ResourceConfig(TestResource.class);
    }

    @Test
    public void test() {
        String response = target("test").request().get(String.class);
        Assert.assertTrue(response.contains("test"));
    }
}

Just add this dependency

<dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-inmemory</artifactId>
    <version>${jersey2.version}</version>
</dependency>

It uses an in-memory container, which is the most efficient for small tests. There are other containers with Servlet support if needed. Just see the link I posted above.

Use PowerMockito on top of Mockito.

Example code:

@RunWith(PowerMockRunner.class)
@PrepareForTest(DriverManager.class)
public class Mocker {

    @Test
    public void shouldVerifyParameters() throws Exception {

        //given
        PowerMockito.mockStatic(DriverManager.class);
        BDDMockito.given(DriverManager.getConnection(...)).willReturn(...);

        //when
        sut.execute(); // System Under Test (sut)

        //then
        PowerMockito.verifyStatic();
        DriverManager.getConnection(...);

    }

More information:

• Why doesn't Mockito mock static methods?

There are several disadvantages to the when/thenReturn, when/thenThrow and when/then syntaxes. For example,

• In the case of when/thenReturn, if the return type is a generic with a wildcard, and you wish to return a mock of the same type, you will be unable to avoid a compile warning.
• You can't use when/thenThrow and when/then for a void method.
• You can't use these syntaxes on Mockito spies.
• You can only call when once for each combination of mock object, method and arguments, unless you call reset on the mock.
• Calling when multiple times for one combination of mock object and method, when you are using argument matchers, can lead to problems.

I find these cases difficult to remember. So instead of trying to keep track of when the when/thenReturn, when/thenThrow and when/then syntaxes will and won't work, I prefer to avoid them completely, in favour of the doReturn/when, doThrow/when and doAnswer/when alternatives. That is to say, since you'll occasionally need doReturn/when, doThrow/when and doAnswer/when, and you can ALWAYS use these methods, there is no point in learning how to use when/thenReturn, when/thenThrow and when/then.

Note that doReturn, doThrow and doAnswer can be chained together in the same way as thenReturn, thenThrow and then. What they don't have is an option for returning several values (or throwing several exceptions, or running several answers) within a single call to doReturn, doThrow and doAnswer. But I find that I need to do this so seldom, that it doesn't really matter.

There's one more disadvantage to doReturn, which I consider insignificant. You don't get compile time checking of the type of its argument, like you do with when/thenReturn. So if you get the argument type wrong, you won't find out until you run your test. Frankly, I don't care.

In summary then, I have been using Mockito for more than two years, and I consider the consistent use of doReturn, doThrow and doAnswer to be a Mockito best practice. Other Mockito users disagree.

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

The sample works if you remove the PowerMock dependencies. The issue is that the versions of Mockito and PowerMock used are incompatible with each other. For PowerMock 2.x you need at least Mockito 2.8.9+. PowerMock provides a compatibility list that shows what version of PowerMock is compatible with what version of Mockito. Fix up the versions to be compatible with each other and your sample will start to work.

New feature added to Mockito makes this even easier,

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

Take a look at Mockito documentation

In case when there are more than one parameters, and capturing of only single param is desired, use other ArgumentMatchers to wrap the rest of the arguments:

verify(mock).doSomething(eq(someValue), eq(someOtherValue), argument.capture());
assertEquals("John", argument.getValue().getName());

The easiest way may be to combine Mockitos Answer with lambdas, streams and iterators. The resulting code is

Iterator<Integer> values = Stream.iterate(0, n -> n + 100).iterator();
when(myClass.myMethod()).thenAnswer(i -> values.next());

The code can be made a little more efficient if you use an IntStream and a PrimitiveIterator.OfInt as the iterator type, but that is probably overkill for a unit test...