InvalidUseOfMatchersException when verifying a final method

[GoogleCodeExporter]

I have 2 tests in the same Junit TestCase class.

The first test is coded liked that:

    @Test
    public void testGetLastUpdates() {
        EntityLogDaoImpl dao = mock(EntityLogDaoImpl.class);
        TrackingServiceImpl service = new TrackingServiceImpl();
        service.setEntityLogDao(dao);
        when(dao.searchLast(anyInt())).thenReturn(mock(List.class));
        service.getEntityLogs(anyInt());
        verify(dao).searchLast(anyInt());
        verify(dao).toEntityLogVOCollection(anyCollection());
    }

Unfortunately, the method toEntityLogVOCollection of the mock object is 
final (it should'nt be, I know).

As a result, the matcher aren't cleaned during the execution of the last 
line. 

From what I understand, it seems that the anyCollection() push a Matcher 
in the MatcherStack of LastArguments. That matcherStack should be cleared 
during the execution of toEntityLogVOCollection. As the this method is 
final the cleaning isn't done. 

=> The secong test method throw an InvalidUseOfMatchersException because 
the MatchersBinders sees 2 matchers instead of one. The one of the first 
test is STILL HERE.

I think Mockito should send a error before that, during the execution of 
the first test, in order to leave the Matchers in a good state. 

BTW I love this framework,
Cheers,

Original issue reported on code.google.com by g.zoritc...@gmail.com on 25 Mar 2009 at 2:28

[GoogleCodeExporter]

>I think Mockito should send a error before that, during the execution of 
>the first test, in order to leave the Matchers in a good state. 

I think too. The problem is that it's impossible in java :) 

The only way to implement it is to put some validateFrameworkState() call in 
every
tearDown() method.

Original comment by szcze...@gmail.com on 27 Mar 2009 at 3:16

[GoogleCodeExporter]

I'm closing this one. There are two features in trunk version that makes the 
problem
vanish.

First, all framework validation problems now have the exception message that 
contains
a navigable (clickable) location of the defect.

Secondly, there is a new MockitoTroubleshooter class that currently enables 
user to
validate the framework state explicitly. This might be helpful for debugging 
some
corner cases and for some eager users who wish to validate the state after each 
test.
Bear in mind that Mockito validates the framework state every time you use it. 
You
can read more in javadoc for MockitoTroubleshooter class:
http://code.google.com/p/mockito/source/browse/trunk/src/org/mockito/MockitoTrou
bleshooter.java

Original comment by szcze...@gmail.com on 21 Apr 2009 at 10:11

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 9 Jun 2009 at 3:15

• Added labels: Milestone-Release1.8

[GoogleCodeExporter]

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

• Added labels: Matchers