No subject


Fri Jan 27 13:32:56 UTC 2012


Looking at mockito, not only the community is vibrant but there is PowerMock (which can use mockito as the mocking provider). That makes two full communities working to make this framework better. And need be we can use PowerMock in RHQ too without changing the mocking framework. (http://code.google.com/p/powermock/)


Here some interesting links to comparison from the jmockit community (... of course they are a little bit biased):
http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix
http://code.google.com/p/jmockit/wiki/MockingToolkitsOnOhloh

With regards to existing infrastructure for mocking, I do not think it would be necessary going forward. mockito provides a less intrusive mechanism to write tests; having that heavy setup (from current RHQ code) might not be required at all. But I would need to investigate the code a little bit more before I have a definitive answer.



Thank you,
Stefan Negrea



----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Monday, January 30, 2012 3:23:26 AM
> Subject: Re: RHQ & mockito
> 
> On Friday, January 27, 2012 16:23:37 Stefan Negrea wrote:
> > 
> > I know that jMock was used in some parts of RHQ however I find
> > mockito
> > superior especially around argument matchers, number of
> > invocations, and
> > call order. Please take a look at this blog post for a detailed
> > comparison:
> > http://www.zsoltfabok.com/blog/2010/08/jmock-versus-mockito/
> > 
> 
> From this I find mockito and jMock equal. The syntax might be a
> little bit
> more elegant in mockito (I find a little bit more explicitness of the
> jMock
> syntax helpful sometimes - the number of invocations examples in the
> above
> blog post is where I find the jMock syntax more understandable), but
> feature-
> wise they are equal. In addition jMock supports tracking of
> unexpected method
> calls on mocks, which I find very useful to keep track of - it is
> great when
> the internals of the implementation classes change and have different
> expectations on the mocks - your tests then start to fail with
> explicit
> messages about unexpected calls and you know what went wrong.
> 
> As for the maven and TestNG integration - in the test-utils project,
> there's
> the JMockTest base class that you can use in your tests. You can also
> use
> @Listener(JMockTest.class) if your test class already inherits from
> another
> base class. Granted, these are not standard, we had to write them,
> but the
> infrastructure is there and is being used in a number of tests.
> With mockito, you'd have to use a very similar approach to what we
> have (
> although we tend to re-create the mocks in each test method manually
> (which
> is what mockito seems to automate in the example (not hard to do with
> our
> impl)), see https://gist.github.com/864185.
> 
> I don't defend jMock as such, personally I don't care what mocking
> framework
> we are going to use, I just don't like the idea of having X solutions
> for
> the same problem in the codebase when each of them brings exactly the
> same
> features to the table. Also there is some infrastructure built around
> jMock
> - see @PluginContainerTest in the test-utils project, which would
> have to be
> duplicated if we wanted to use it with mockito based tests later on.
> 
> Lukas
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list