shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: Mockito rocks
Date Sat, 16 Oct 2010 20:10:58 GMT
Uh huh, it becomes an ideological battle :) First of all, depending on
the project, I've used and still use JMock, EasyMock and Mockito all
the time. There's absolutely no point using more than one in any given
project - they all bring in similar feature set with a bit different
emphasis and ease-of-use. Mockito's syntax feels the most natural and
concise to me. I've never been a fan of EasyMock's explicit
record/replay. I also don't like strict verification because too often
it becomes a maintenance burden and it may inconspiciously lead you to
testing what the code is doing as opposed to what it should be doing
(the infamous antipattern "my code is testing my mocks").

To me, the winner is almost always the one that lets me write less
code and arguably Mockito helps with that. I can certainly live with
EasyMock since I don't have time to rewrite the tests myself but if
Alan wants to do that and has the time, I wouldn't object. I don't
think we should fear of breaking the tests - fixing the tests should
always be the highest priority but we should be bold about refactoring
in order to improve the quality. Also, I don't agree that more tests
is automatically good. Every line of code we write needs to be
maintained and just as with application/business code, there can be
good and bad test code as well (speaking from experience, I've seen it
all...). It's always useful to audit the codebase from time to time,
after all that's why they make new editions of books as well. So if
Alan is willing to do the work and from my experience it makes sense,
then the prize for you Les would merely be the effort required to
learn the new library - which could be a positive as well. However, if
you or anybody feels strongly about the issue, I'm fine with status
quo as well.

Kalle


On Sat, Oct 16, 2010 at 10:58 AM, Les Hazlewood <lhazlewood@apache.org> wrote:
> I've personally never used Mockito before and don't have any issues
> with trying it out, but from what I've heard, it doesn't really reduce
> or simplify unit testing that much for 'real world' test cases.
>
> For example, Mockito claims that you don't have to 'train' your mocks
> up front like you do with EasyMock.  But IIUC, you have to write a lot
> of verify statements at the end of the test if you want to have a
> decent/valid assertion of behavior.  So the labor of the Mockito
> assert methods seems to me no different than the EasyMock expect
> methods: where the only difference being where do you want to do the
> work: at the beginning of the unit test or the end.
>
> In fact, you still have to stub Mockito mocks (like EasyMock) before
> you execute your method under test so it seems like there'd be _more_
> code w/ Mockito, i.e.
>
> EasyMock:
> stub behavior/return values (multiple calls):
> call your method under test
> verify(mock); //one call
> assert one or two things
>
> Mockito:
> stub behavior/return values (multiple calls):
> call your method under test
> assert a lot of things (multiple calls);
>
> Also, Mockito doesn't have any strict mocks - sometimes strict mocks
> are good things depending on your test case.  A blanket statement that
> 'all mocks are nice' seems dangerous considering you can choose your
> flavor with EasyMock depending on what is appropriate for the test
> case.  Also, look at the 'In Order' example here:
> http://code.google.com/p/mockito/wiki/MockitoVSEasyMock  That seems
> less readable than the EasyMock version IMO (and points to the
> multiple assert statements that you have to write).
>
> Anyway, this is what I've gleamed from their website and what I've
> heard from one or two others, so I'd love to hear what you guys think
> about this given that you both have real world experience with it.
>
> Mockito API aside, one struggle for me here is that it seems 1) silly
> to re-write any existing test code because doing so could break test
> cases and that's really risky and 2) if EasyMock remains because of
> this, then we'd have two mock frameworks interspersed and that just
> seems like a maintenance pain.
>
> But then again, having more tests is a *great* thing, so if people
> feel more inclined to actually write more tests if they can use their
> preferred API, that's the best result IMO.
>
> I'd love to hear about your own experiences.  At the end of the day,
> more testing is great, and we're an open source project that can have
> fun with this stuff, so I'm all for trying it out.  I just don't know
> that we'd want to get rid of EasyMock.
>
> Best,
>
> Les
>

Mime
View raw message