No subject


Fri Jan 27 13:32:56 UTC 2012


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


More information about the rhq-devel mailing list