Issue #36 resolved

Matchers don't work but mocks do

Pankaj Tandon
created an issue

I'm trying to use this with Spring MVC testing:

I used springockito to create my mocks using xml config in a file called mock-services-context.xml like so:

<mockito:mock id="userService" class="" />

Then I configured my tests like so:

@ContextConfiguration(locations={"/META-INF/spring/api-bootstrap-context.xml", "classpath:mock-services-context.xml"})
public class AuthenticationControllerTests {

In my setup, I extracted the user bean to try to mock it.

    public void setup() {
        //Build  the MVC context
        this.mockMvc = webAppContextSetup(this.wac).build();        
        user = new User();
        userService = wac.getBean("userService", UserService.class);
        when(userService.findUserByPlainTextCredentials(anyString(), anyString())).thenReturn(user);

That last line is where it blows up. The matchers don't seem to work with the mocked object.

But when I replace the expectation like so:

        when(userService.findUserByPlainTextCredentials("joe", "secret")).thenReturn(user);

all works fine.

I did confirm that userService is a mocked CGLIB proxy.

Here's the stack:

Misplaced argument matcher detected here:
-> at

You cannot use argument matchers outside of verification or stubbing.
Examples of correct usage of argument matchers:
    doThrow(new RuntimeException()).when(mock).someVoidMethod(anyObject());

Also, this error might show up because you use argument matchers with methods that cannot be mocked.
Following methods *cannot* be stubbed/verified: final/private/equals()/hashCode().

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.lang.reflect.Method.invoke(
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(
    at org.junit.internal.runners.statements.RunBefores.evaluate(
    at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(
    at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(
    at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(
    at org.junit.runners.ParentRunner$
    at org.junit.runners.ParentRunner$1.schedule(
    at org.junit.runners.ParentRunner.runChildren(
    at org.junit.runners.ParentRunner.access$000(
    at org.junit.runners.ParentRunner$2.evaluate(
    at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(
    at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(

Any idea why the matchers don't work?

Thanks for the great work, tho' Just what we need at this point!

Comments (8)

  1. Philip Maes

    The problem is in ThreadLocalMockMethodInterceptor<T> which adds a wrap around the mock.

    Then, when Mockito.verify or Mockito.when(mock.method(matcheris)) are called, there is a test in Mockito to check if the given mock is a MockitoMock. Conditions to be a true MockitoMock are to be !=null and that the callback of the mock is instanceof MethodInterceptorFilter, which is not anymore the case, so the mock is not recognized as a Mockito mock. (CglibMockMaker, method getHandler(Object mock) line ~39)

    I don't know why this is needed because the one of Mockito is already fine for that purpose.

    So the solution is simply to fork this repo and delete the class ThreadLocalMockMethodInterceptor.

  2. kubek2k repo owner

    I think the problem is solved in 1.0.7 - I resigned from thread locals - the idea was to make mocks be able to work in a multithreaded environment, but it feels like its not the time yet :|. Please recheck

  3. Log in to comment