RHQ & mockito

Ian Springer ian.springer at redhat.com
Fri Feb 3 14:08:13 UTC 2012


Hi Stefan,

Looking good. I agree the mock APIs are pretty readable, even for 
someone like me with no experience with mocking frameworks.

It seems like you might be mocking more than needed though. 
Specifically, I wonder if mocking the directory being discovered (i.e. 
File.listFiles()) is a good idea. In that case it is almost as easy to 
create a real directory on the filesystem containing real files, which I 
think would make the test more realistic and potentially catch things 
the mocked directory would not (e.g. file permission nuances, issues 
with the code that calculates checksums, etc.).

--Ian

On 02/03/2012 01:04 AM, Stefan Negrea wrote:
> Hello Everybody,
>
> I had a lengthy chat with Lukas on Tuesday regarding this and I think we got on the same page. He was more concerned with the actual plan to migrate existing tests (that make use of other mocking framework) to the new framework of choice. In the short term this is not going to be an issue because I will focus on testing only changes to the content system. All these changes are in classes that do not have mocking dependencies in respective test code. So for the short term, I will just add new tests that make use of mockito and PowerMock for mocking dependencies.
>
> As far as long term goes, from the test code I wrote so far I can say that using mockito with PowerMock is easier than I thought. The test code is compact and nice, the APIs are very robust, and the documentation for each framework is top-notch. Here is a sample set of tests that use mockito and PowerMock:
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=696f61d5eda164544bc953add9348bf88248cabd
>
> This sample code is a good indication that future test code refactoring to use mockito and PowerMock will not be very difficult and will improve code readability.
>
>
> Thank you,
> Stefan Negrea
>
> ----- Original Message -----
>> From: "Stefan Negrea"<snegrea at redhat.com>
>> To: rhq-devel at lists.fedorahosted.org
>> Sent: Monday, January 30, 2012 4:55:57 PM
>> Subject: Re: RHQ&  mockito
>>
>> 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
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com



More information about the rhq-devel mailing list