EasyMock auto replay/verify?

[GoogleCodeExporter]

(Not a defect).

I really like how the @Mocks are automagically created but it really pains
me to have to replay and verify them for each test.

I have written the attached helper class to replay and verify all @Mock and
@Stub test members.  (Note I'm using easymock classextensions).

Do you have any thoughts on how replay/verify functionality could be
integrated into atunit?

Original issue reported on code.google.com by alison.r...@gmail.com on 23 Nov 2007 at 1:02

Attachments:

• EasyMockFrameworkHelper.java

[GoogleCodeExporter]

Thanks for the helper!  I can definitely see that integrating this into AtUnit 
would
be very helpful.  I'll have to give some thought to what that integration would 
look
like exactly.  My initial thought is attached.  You could get fancier than 
this.  I
have some ideas for hiding the replay and verify steps entirely, but they're
half-baked and I'm not really sure it should be done at all.

Original comment by logan.jo...@gmail.com on 24 Nov 2007 at 3:53

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

Attachments:

• TestWithHelper.java

[GoogleCodeExporter]

Original comment by logan.jo...@gmail.com on 24 Nov 2007 at 4:10

[GoogleCodeExporter]

How about something along the lines of Spring's AssertThrows helper test?  A 
class
that establishes the template for test execution with replays and verifies.

See attached for a thought I had...

Original comment by alison.r...@gmail.com on 26 Nov 2007 at 11:39

Attachments:

• AssertExpectReplayVerifyAssert.java
• TestQuoteServiceImpl.java

[GoogleCodeExporter]

Maybe with a different name... :)

Original comment by alison.r...@gmail.com on 26 Nov 2007 at 11:59

[GoogleCodeExporter]

Here's a version that supports checking where you want an Exception to occur.

Test implementations that expect exceptions can just override 
handleException(Exception).

Original comment by alison.r...@gmail.com on 27 Nov 2007 at 1:01

Attachments:

• AssertExpectReplayVerifyAssert.java

[GoogleCodeExporter]

Wow.  I can see how that would help structure a test, if the author can get 
past the
syntax of it.  I really like your original helper better, though-- it's less 
verbose
and doesn't make the test look all exotic.  The goal should I think generally 
be less
boilerplate, rather than more (helpful) boilerplate.

The only thing blocking integration of the helper (other than lack of time) is 
that
I'm not sure whether I can get hold of mocks created directly via EasyMock 
(rather
than through AtUnit's @Mock and @Stub annotations).  If I can't, 
helper.replayAll()
would only work for mocks created by AtUnit, but its name implies otherwise.  I 
don't
want to force the test author to avoid EasyMock, or use some EasyMock wrapper, 
or
anything like that.

Do you know if EasyMock provides some kind of introspection API that would be 
useful
here?  If not, I'm considering going to AspectJ and intercepting calls to 
EasyMock or
something.

Original comment by logan.jo...@gmail.com on 27 Nov 2007 at 1:04

[GoogleCodeExporter]

punted on this for 1.0-- the release was already too delayed.  

I've been looking at options, though.  I think what we can do is wrap the @Unit 
field
in a cglib proxy right before the test method is executed.  The proxy will, on 
first
method invocation, replay all the mocks.  After the test method, we can verify 
all
the mocks and unwrap the @Unit field.  Trick is to find a way to do it that 
isn't too
much of a hack.

Original comment by logan.jo...@gmail.com on 19 Dec 2007 at 3:42

[GoogleCodeExporter]

A cheap alternative is to add a parameter to @Mock that specifies that the field
should not be initialized by AtUnit.
This way you can safely look for the annotated fields ant the user can create 
the
mocks using EasyMock (or his/her mock framework of choice). The only restriction
would be that the mock must be a field, not a local variable.

Original comment by migueldi...@gmail.com on 9 Jan 2008 at 6:35