ssacher-tgm / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

Documentation update: Order of creating matchers is significant #183

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Match a method's second parameter 
2. Mock the method's invocation using eq(...) and the already created matcher.
3. The matchers are matched in inverse order, because the second matcher
was created first.

What is the expected output? What do you see instead?
The method invocation is not matched correctly, as if I never mocked the
invocation.

What version of the product are you using? On what operating system?
Mockito 1.8.4 on Sun/Obstacle Java 1.6.0_19 on Windows XP

Please provide any additional information below.

import java.util.HashMap;
import java.util.Map;

import junit.framework.TestCase;

import org.mockito.Mockito;

public class MockTest extends TestCase
{
    private static interface Foo
    {
        int doStuff(String s, Map<String,Object> map);
    }

    public void testMock()
    {
        Foo foo = Mockito.mock(Foo.class);

        @SuppressWarnings("unchecked")
        Map<String,Object> anyMap = (Map<String,Object>) Mockito.any();
        Mockito.when(foo.doStuff(Mockito.eq("abc"), anyMap)).thenReturn(3);

        assertEquals(3, foo.doStuff("abc", new HashMap<String,Object>()));
    }

    public void testMock2()
    {
        Foo foo = Mockito.mock(Foo.class);

        String eqABC = Mockito.eq("abc");
        @SuppressWarnings("unchecked")
        Map<String,Object> anyMap = (Map<String,Object>) Mockito.any();
        Mockito.when(foo.doStuff(eqABC, anyMap)).thenReturn(3);

        assertEquals(3, foo.doStuff("abc", new HashMap<String,Object>()));
    }
}

Note that the second test case seems to work, but in my production code
declaring both matchers in local variables got me the following error
(first argument is not String though, but a custom session ID object):
org.mockito.exceptions.misusing.InvalidUseOfMatchersException: 
Invalid use of argument matchers!
3 matchers expected, 2 recorded.
This exception may occur if matchers are combined with raw values:
    //incorrect:
    someMethod(anyObject(), "raw String");
When using matchers, all arguments have to be provided by matchers.
For example:
    //correct:
    someMethod(anyObject(), eq("String by matcher"));

If this is not deemed a bug, at least there should be some strong warnings
in the documentation.  Java+generics pretty much forces you to suppress
some warnings when using parameterized Map<> types, so declaring matchers
in local variables seems natural to me.

Original issue reported on code.google.com by ulrich.h...@gmail.com on 12 Apr 2010 at 7:17

GoogleCodeExporter commented 8 years ago
Hey,

Bear in mind that Mockito.any() (and similar methods) do not create matchers. 
Those
are not factory methods.

Matcher m = ...;      //matcher creation
mock.foo(argThat(m)); //using the matcher via 'argThat' method.

Honestly, I hate the way arg matchers are implemented. In dynamic languages it 
is way
easier & elegant to do it. Unfortunately, we use java and we have to hack 
around :)
Using matcher methods is order sensitive because of java evaluation sequence. 

If you find a better way to implement matchers in Mockito - hack on the 
sources. If
you have suggestions on the updates to javadocs - please tell me where & what 
needs
to be added.

Thanks!

PS.
Instead of:
(Map<String,Object>) Mockito.any()
you can do:
(Map) any() or anyMap()
and deprecated warnings in the test.

Original comment by szcze...@gmail.com on 12 Apr 2010 at 9:19

GoogleCodeExporter commented 8 years ago

Original comment by szcze...@gmail.com on 24 May 2010 at 5:45

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r2014.

Original comment by szcze...@gmail.com on 14 Jun 2010 at 9:02

GoogleCodeExporter commented 8 years ago

Original comment by szcze...@gmail.com on 3 Jul 2011 at 12:43

GoogleCodeExporter commented 8 years ago

Original comment by brice.du...@gmail.com on 2 Dec 2012 at 10:21