Re: mocking library

[Timothy Chen <tn...@gmail.com>]

Just FYI I'm adding jmockit as I'm adding tests for the JsonRecordReader.
The FragmentContext class has lots of dependencies and I remembered our
conversation here.

Tim


On Fri, Feb 15, 2013 at 3:26 PM, Jacques Nadeau <ja...@gmail.com>wrote:

> Hey Chris,
>
> It sounds like people have had the most positive experiences with jmockit
> and mockito with jmockit seeming to gain some traction.  Do you want to try
> out jmockit on your stuff and see how it goes?
>
> Jacques
>
> On Fri, Feb 15, 2013 at 12:55 PM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > Last time I tried PowerMock, I was unable to mock System.nanoTime nor
> > properly fake classes.
> >
> > On Fri, Feb 15, 2013 at 3:03 AM, Stevo Slavić <ss...@gmail.com> wrote:
> >
> > > +1 (non-binding) for jmockit. After being easymock user for years, I've
> > > turned to jmockit on recent projects and it has proven to be really
> > > powerful.
> > > Nice overview with rationale and comparison can be found here:
> > > http://jmockit.googlecode.com/svn/trunk/www/about.html
> > >
> > > One downside I've noticed, which comes from all that power of being
> able
> > to
> > > mock anything entirely or partially, is that sometimes it's not that
> > > obvious why build has failed. With jmockit instrumentation if a test
> > fails,
> > > e.g. SUT dependency mocked but with default settings (so without static
> > > initialization mocked), some other tests running in parallel or after
> > > failed one might fail as well so, it might look like that there's
> > something
> > > wrong with testing frameworks/tools, but actually root cause is an
> > invalid
> > > test.
> > >
> > > Another small downside is that APIs tended to change in
> > > non-backward-compatible way. I guess that's acceptable for releases
> > before
> > > recently published 1.0, and we'll see what future will bring. Older
> > > versions would allow misuse, and newer ones perform various checks so
> are
> > > more strict, thus the changes were for better (e.g. before it was
> > possible
> > > by mistake to record two different non strict expectations/behaviors
> for
> > > same mocked method on same mocked instance).
> > >
> > > Make sure to use latest version, older ones had issues with Java 7
> > > compiler.
> > >
> > > Kind regards,
> > > Stevo Slavic.
> > >
> > >
> > > On Fri, Feb 15, 2013 at 10:29 AM, Ed Kohlwey <ek...@gmail.com>
> wrote:
> > >
> > > > That matrix is quite impressive. This is the first time I've come
> > across
> > > > JMockit but I may start using it soon - it seems very fully featured
> > and
> > > > the syntax is quite elegant.
> > > >
> > > >
> > > > On Thu, Feb 14, 2013 at 11:53 AM, Jacques Nadeau <
> > > jacques.drill@gmail.com
> > > > >wrote:
> > > >
> > > > > Rather than reinvent the pros/cons wheel here, does someone want to
> > > find
> > > > a
> > > > > couple of evaluations/discussions that other Apache projects did
> and
> > > see
> > > > > what conclusions they came to?
> > > > >
> > > > > Interesting comparison here, of course probably skewed since
> Jmockit
> > > > built
> > > > > it and has the most features....
> > > > >
> > > > >
> http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Feb 14, 2013 at 8:47 AM, Ted Dunning <
> ted.dunning@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > For me, the ability to mock statics and final classes is a big
> > > > > requirement.
> > > > > >
> > > > > > On Thu, Feb 14, 2013 at 7:41 AM, Ed Kohlwey <ek...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > The power mock/easy mock combo is also quite effective and has
> > one
> > > of
> > > > > the
> > > > > > > cleanest and easiest to understand  interfaces I've seen in a
> > > mocking
> > > > > > > library, however I'm not familiar with Jmockit.
> > > > > > > On Feb 13, 2013 11:42 AM, "Ted Dunning" <ted.dunning@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > > > For basic mocking, none of the libraries make much
> difference.
> > > >  Once
> > > > > > you
> > > > > > > > go beyond that, however, there is a world of difference,
> > > > particularly
> > > > > > to
> > > > > > > do
> > > > > > > > with mocking static members and methods and the mocking of
> > system
> > > > > > > classes.
> > > > > > > >
> > > > > > > > For example, in testing some fixes to Zookeeper, I needed to
> > mock
> > > > > > > > System.nanoTime() and System.currentTimeMillies().  This sort
> > of
> > > > > > problem
> > > > > > > > pops up pretty commonly when testing an object in the context
> > of
> > > a
> > > > > > legacy
> > > > > > > > environment that wasn't designed for testing.
> > > > > > > >
> > > > > > > > For the Zookeeper and mapr-spout, I have been using jmockit
> > with
> > > > good
> > > > > > > > results.  It can even mock final static system methods.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Feb 12, 2013, at 12:00 PM, Timothy Chen wrote:
> > > > > > > >
> > > > > > > > > I was thinking about to use Mocks when I was doing Join
> > > earlier,
> > > > > glad
> > > > > > > > > you've raised this!
> > > > > > > > >
> > > > > > > > > I've mostly used Mockito in the past, don't know if there
> is
> > > any
> > > > a
> > > > > > lot
> > > > > > > > > better option out there.
> > > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > Tim
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Feb 12, 2013 at 8:50 AM, Christopher Merrick <
> > > > > > > > > christopherrmerrick@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > >> Hi Team -
> > > > > > > > >>
> > > > > > > > >> I'm going to take a stab at putting together some unit
> tests
> > > > for a
> > > > > > few
> > > > > > > > of
> > > > > > > > >> these reference operator implementations that we have
> built.
> > >  I
> > > > > > don't
> > > > > > > > see a
> > > > > > > > >> mocking library imported into the project yet, and I
> wanted
> > to
> > > > see
> > > > > > if
> > > > > > > > >> anyone has strong opinions about which to use.  I have
> used
> > > > > mockito
> > > > > > in
> > > > > > > > the
> > > > > > > > >> past and was generally pretty happy with it - does anyone
> > > have a
> > > > > > > > preference
> > > > > > > > >> other than this?
> > > > > > > > >>
> > > > > > > > >> cheers,
> > > > > > > > >> Chris
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: mocking library

[Ted Dunning <te...@gmail.com>]

Interesting.

I have just been having fits with jmockit.  It mocks very nicely.  But the
mocks tend to stick around longer than I want them to.  Very frustrating.


On Mon, May 20, 2013 at 9:59 PM, Timothy Chen <tn...@gmail.com> wrote:

> Just FYI I'm adding jmockit as I'm adding tests for the JsonRecordReader.
> The FragmentContext class has lots of dependencies and I remembered our
> conversation here.
>
> Tim
>
>
> On Fri, Feb 15, 2013 at 3:26 PM, Jacques Nadeau <jacques.drill@gmail.com
> >wrote:
>
> > Hey Chris,
> >
> > It sounds like people have had the most positive experiences with jmockit
> > and mockito with jmockit seeming to gain some traction.  Do you want to
> try
> > out jmockit on your stuff and see how it goes?
> >
> > Jacques
> >
> > On Fri, Feb 15, 2013 at 12:55 PM, Ted Dunning <te...@gmail.com>
> > wrote:
> >
> > > Last time I tried PowerMock, I was unable to mock System.nanoTime nor
> > > properly fake classes.
> > >
> > > On Fri, Feb 15, 2013 at 3:03 AM, Stevo Slavić <ss...@gmail.com>
> wrote:
> > >
> > > > +1 (non-binding) for jmockit. After being easymock user for years,
> I've
> > > > turned to jmockit on recent projects and it has proven to be really
> > > > powerful.
> > > > Nice overview with rationale and comparison can be found here:
> > > > http://jmockit.googlecode.com/svn/trunk/www/about.html
> > > >
> > > > One downside I've noticed, which comes from all that power of being
> > able
> > > to
> > > > mock anything entirely or partially, is that sometimes it's not that
> > > > obvious why build has failed. With jmockit instrumentation if a test
> > > fails,
> > > > e.g. SUT dependency mocked but with default settings (so without
> static
> > > > initialization mocked), some other tests running in parallel or after
> > > > failed one might fail as well so, it might look like that there's
> > > something
> > > > wrong with testing frameworks/tools, but actually root cause is an
> > > invalid
> > > > test.
> > > >
> > > > Another small downside is that APIs tended to change in
> > > > non-backward-compatible way. I guess that's acceptable for releases
> > > before
> > > > recently published 1.0, and we'll see what future will bring. Older
> > > > versions would allow misuse, and newer ones perform various checks so
> > are
> > > > more strict, thus the changes were for better (e.g. before it was
> > > possible
> > > > by mistake to record two different non strict expectations/behaviors
> > for
> > > > same mocked method on same mocked instance).
> > > >
> > > > Make sure to use latest version, older ones had issues with Java 7
> > > > compiler.
> > > >
> > > > Kind regards,
> > > > Stevo Slavic.
> > > >
> > > >
> > > > On Fri, Feb 15, 2013 at 10:29 AM, Ed Kohlwey <ek...@gmail.com>
> > wrote:
> > > >
> > > > > That matrix is quite impressive. This is the first time I've come
> > > across
> > > > > JMockit but I may start using it soon - it seems very fully
> featured
> > > and
> > > > > the syntax is quite elegant.
> > > > >
> > > > >
> > > > > On Thu, Feb 14, 2013 at 11:53 AM, Jacques Nadeau <
> > > > jacques.drill@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Rather than reinvent the pros/cons wheel here, does someone want
> to
> > > > find
> > > > > a
> > > > > > couple of evaluations/discussions that other Apache projects did
> > and
> > > > see
> > > > > > what conclusions they came to?
> > > > > >
> > > > > > Interesting comparison here, of course probably skewed since
> > Jmockit
> > > > > built
> > > > > > it and has the most features....
> > > > > >
> > > > > >
> > http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Feb 14, 2013 at 8:47 AM, Ted Dunning <
> > ted.dunning@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > For me, the ability to mock statics and final classes is a big
> > > > > > requirement.
> > > > > > >
> > > > > > > On Thu, Feb 14, 2013 at 7:41 AM, Ed Kohlwey <
> ekohlwey@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > The power mock/easy mock combo is also quite effective and
> has
> > > one
> > > > of
> > > > > > the
> > > > > > > > cleanest and easiest to understand  interfaces I've seen in a
> > > > mocking
> > > > > > > > library, however I'm not familiar with Jmockit.
> > > > > > > > On Feb 13, 2013 11:42 AM, "Ted Dunning" <
> ted.dunning@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > For basic mocking, none of the libraries make much
> > difference.
> > > > >  Once
> > > > > > > you
> > > > > > > > > go beyond that, however, there is a world of difference,
> > > > > particularly
> > > > > > > to
> > > > > > > > do
> > > > > > > > > with mocking static members and methods and the mocking of
> > > system
> > > > > > > > classes.
> > > > > > > > >
> > > > > > > > > For example, in testing some fixes to Zookeeper, I needed
> to
> > > mock
> > > > > > > > > System.nanoTime() and System.currentTimeMillies().  This
> sort
> > > of
> > > > > > > problem
> > > > > > > > > pops up pretty commonly when testing an object in the
> context
> > > of
> > > > a
> > > > > > > legacy
> > > > > > > > > environment that wasn't designed for testing.
> > > > > > > > >
> > > > > > > > > For the Zookeeper and mapr-spout, I have been using jmockit
> > > with
> > > > > good
> > > > > > > > > results.  It can even mock final static system methods.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Feb 12, 2013, at 12:00 PM, Timothy Chen wrote:
> > > > > > > > >
> > > > > > > > > > I was thinking about to use Mocks when I was doing Join
> > > > earlier,
> > > > > > glad
> > > > > > > > > > you've raised this!
> > > > > > > > > >
> > > > > > > > > > I've mostly used Mockito in the past, don't know if there
> > is
> > > > any
> > > > > a
> > > > > > > lot
> > > > > > > > > > better option out there.
> > > > > > > > > >
> > > > > > > > > > +1
> > > > > > > > > >
> > > > > > > > > > Tim
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Feb 12, 2013 at 8:50 AM, Christopher Merrick <
> > > > > > > > > > christopherrmerrick@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > >> Hi Team -
> > > > > > > > > >>
> > > > > > > > > >> I'm going to take a stab at putting together some unit
> > tests
> > > > > for a
> > > > > > > few
> > > > > > > > > of
> > > > > > > > > >> these reference operator implementations that we have
> > built.
> > > >  I
> > > > > > > don't
> > > > > > > > > see a
> > > > > > > > > >> mocking library imported into the project yet, and I
> > wanted
> > > to
> > > > > see
> > > > > > > if
> > > > > > > > > >> anyone has strong opinions about which to use.  I have
> > used
> > > > > > mockito
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > >> past and was generally pretty happy with it - does
> anyone
> > > > have a
> > > > > > > > > preference
> > > > > > > > > >> other than this?
> > > > > > > > > >>
> > > > > > > > > >> cheers,
> > > > > > > > > >> Chris
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>