No subject


Fri Jan 27 13:32:56 UTC 2012


Now getting back to this particular example. The method under test was fairly simple and the mocking framework has all the features needed. I think I was able to write those tests faster than writing code to actually create the folder structure for each test. I think it would be very easy now to simulate all sorts of errors (eg. permission exceptions). Basically one needs to copy an existing complex test and trim it down to the mock only dependencies needed up to the exception. I focused on adding tests only for content system changes but we can definitely do some experiments on those tests after I merge into master.



Thank you,
Stefan Negrea

----- Original Message -----
> From: "Ian Springer" <ian.springer at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, February 3, 2012 8:08:13 AM
> Subject: Re: RHQ & mockito
> 
> 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
> 
> _______________________________________________
> 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