RHQ & mockito

Stefan Negrea snegrea at redhat.com
Mon Jan 30 22:55:57 UTC 2012


Hello Lukas,

I reviewed the JMockTest and PluginContainerTest code. There are two different scenarios covered by these classes: straight usage of mocking contexts and mocking contexts in conjunction with ThreadLocal.


I do not see the need to duplicate any functionality with regards to straight usage of mocking contexts. With mockito all that goes away with annotations or static imports of the mocking framework. Also worth noting is plain mocking contexts from JMockTest are used in all but three inheriting test classes. So the bulk of the code will get less complex with this change.

Sample code 1 (to create a test):
import static org.mockito.Mockito.*;
...
ClassUnderTest objectUnderTest = mock(ClassUnderTest.class);


Sample code 2 (to create a test with annotations [1]):

@Mock
private ClassUnderTest objectUnderTest;


@BeforeClass
public void setup() {
   MockitoAnnotations.initMocks(this);
}


With regards to ThreadLocal, mockito does use ThreadLocal under the covers. So most of the code already implemented in JMockTest will not be necessary since the framework does that already. There might be a need for some extra code to align mockito with the TestNG life-cycle but should be less complex than what is already there. So far I found only three test classes where this would apply.


I am writing this with the idea of just doing a pure drop-in replacement. We might be able to make the code less complex with some refactoring. No need to have extra complicated code mixed with mocking, straight usage is much more efficient and preferred when it comes to mocking. But this is a long term concern; initially I want to just add tests to the parts of the content system affected by recent changes.


Thank you,
Stefan Negrea



[1] http://code.google.com/p/mockito/issues/detail?id=304
----- 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