More matches recorded than expected - Easymock fails from Maven, not from Eclipse

Question

I have a strange problem with Easymock 3.0 and JUnit 4.8.2. The problem only occurs when running tests from Maven, and not from Eclipse.

This is unit test (very simple):

... protected ValueExtractorRetriever mockedRetriever; ... @Before public void before() { mockedRetriever = createStrictMock(ValueExtractorRetriever.class); } @After public void after() { reset(mockedRetriever); } @Test public void testNullValueExtractor() { expect(mockedRetriever.retrieve("PROP")).andReturn(null).once(); replay(mockedRetriever); ValueExtractor retriever = mockedRetriever.retrieve("PROP"); assertNull(retriever); assertTrue(true); } 

And I get:

java.lang.IllegalStateException: 1 responder, 2 recorded, expected.

It is strange that I do not even use argument matching. And this is the only test method! and to make it worse, it works from Eclipse and does not work with Maven!

I found some links that did not give me an answer:

• stack overflow
• Expected exceptions in JUnit

If I change the unit test and add another method (which uses an argument match):

 @Test public void testIsBeforeDateOk() { expect(mockedRetriever.retrieve((String)anyObject())).andReturn(new PofExtractor()).anyTimes(); replay(this.mockedRetriever); FilterBuilder fb = new FilterBuilder(); assertNotNull(fb); CriteriaFilter cf = new CriteriaFilter(); assertNotNull(cf); cf.getValues().add("2010-12-29T14:45:23"); cf.setType(CriteriaType.DATE); cf.setClause(Clause.IS_BEFORE_THE_DATE); CriteriaQueryClause clause = CriteriaQueryClause.fromValue(cf.getClause()); assertNotNull(clause); assertEquals(CriteriaQueryClause.IS_BEFORE_THE_DATE, clause); clause.buildFilter(fb, cf, mockedRetriever); assertNotNull(fb); Filter[] filters = fb.getFilters(); assertNotNull(filters); assertEquals(filters.length, 1); verify(mockedRetriever); logger.info("OK"); } 

This last method passes the test, not the other. How is this possible!?!?!

Regards, Nico

Other links:

"bartling.blogspot.com/2009/11/using-argument-matchers-in-easymock-and.html"

"www.springone2gx.com/blog/scott_leberknight/2008/09/the_n_matchers_expected_m_recorded_problem_in_easymock"

"stackoverflow.com/questions/4605997/3-matchers-expected-4-recorded"

Answer 1

I had a very similar problem, and I wrote my findings from the link below. http://www.flyingtomoon.com/2011/04/unclosed-record-state-problem-in.html (just updated)

I believe that the problem is in another test that affects your current test. The problem is another test class, and this affects your test. To find the place of the real problem, I advise you to disable the problem tests one by one until you report a failure.

Actually, this is what I did. I turned off the failed tests one by one until I found the problem test. I found a test that throws an exception and catches the annotation "@extected" without stopping recording.

Answer 2

I believe the first error message

java.lang.IllegalStateException: 1 expected, 2 entries.

means your mockedRetriever methods mockedRetriever called twice, but the test expects it to be called once. So your configuration of Eclipse and Maven is different.

And I have no reason to reset mock after the test. Just keep in mind that JUnit creates a new instance of the class for each test method.

Edition:

How about why the last test method passed the answer:

 expect(mockedRetriever.retrieve((String)anyObject())).andReturn(new PofExtractor()).anyTimes(); 

But in your first test method, this is:

 expect(mockedRetriever.retrieve("PROP")).andReturn(null).once(); 

as an equivalent:

 expect(mockedRetriever.retrieve("PROP")).andReturn(null); 

Answer 3

We had this problem recently, and it only developed when we ran the entire test suite (1100+ test cases). In the end, I found that I could put a breakpoint on the test that exploded, and then return to the list of tests that Eclipse had already run, looking for the previous test case that set the false correctly.

Our problem turned out to be those who use EasyMock.anyString() outside the EasyMock.expect(...) operator. Of course, two tests were done before that did not work.

Thus, in essence, what happened was that improper use of the helper outside the wait statement poisoned the state of EasyMock, and the next time we tried to create a layout, EasyMock would explode.