Differences between jMock & Mockito

[floehopper]

I'm interested in the pros & cons of jMock versus Mockito? Is the
choice just a matter of personal taste or are there more fundamental
issues I should be aware of?

A comment [1] by Steve on Dan North's blog seems to suggest that jMock
will become syntactically noisy when your design is poor, but that
Mockito will stay syntactically quiet and allow you to get away it.
Have I understood that correctly? Can you elaborate? Do you have any
concrete examples?

Thanks, James.

[1] http://dannorth.net/2008/09/the-end-of-endotesting#comment-17523

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Isaiah]

I think there are two fundamental issues, The original intent of mocks was to use it as a tool to discover roles, and design the communication protocols between objects.
Jmock  is better tool if this is how you intended to use mock object. Jmock will highlight badly designed communication protocols between object under test and its collaborators. On the other hand, frameworks like mockito by default ignore all calls between the object under test and it's mocked collaborator(s) and only verifies calls you explicitly specify. If the communication protocol between object undertest and its collaborators is poorly deigned (very chatty, exposing implementation details etc) a framework like mokito will not highlight this, it would silence these issues. In jmock, the test would become very brittle and very difficult to write.

The other fundamental issue is jmock will get you started off by thinking about the contracts or communication protocols between objects, because you have to specify the expeceted messages before you exercies the object under test.

jmock is highly opiniated tool specifically designed as a tool to design object protocols and discover role interfaces, mockito is designed to simply isolate external dependecies and make testing easier.

Cheers
Isaiah

On Fri, Oct 23, 2009 at 10:47 AM, James Mead <jamesmead44@...> wrote:

I'm interested in the pros & cons of jMock versus Mockito? Is the
choice just a matter of personal taste or are there more fundamental
issues I should be aware of?

A comment [1] by Steve on Dan North's blog seems to suggest that jMock
will become syntactically noisy when your design is poor, but that
Mockito will stay syntactically quiet and allow you to get away it.
Have I understood that correctly? Can you elaborate? Do you have any
concrete examples?

Thanks, James.

[1] http://dannorth.net/2008/09/the-end-of-endotesting#comment-17523

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
Isaiah Perumalla

[Nat Pryce]

Hi James. The only comparison I know of is
http://rrees.wordpress.com/2009/04/12/three-little-mockers/

--Nat

On Friday, October 23, 2009, James Mead <jamesmead44@...> wrote:

> I'm interested in the pros & cons of jMock versus Mockito? Is the
> choice just a matter of personal taste or are there more fundamental
> issues I should be aware of?
>
> A comment [1] by Steve on Dan North's blog seems to suggest that jMock
> will become syntactically noisy when your design is poor, but that
> Mockito will stay syntactically quiet and allow you to get away it.
> Have I understood that correctly? Can you elaborate? Do you have any
> concrete examples?
>
> Thanks, James.
>
> [1] http://dannorth.net/2008/09/the-end-of-endotesting#comment-17523
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Julian Hall-2]

isaiah perumalla wrote:
> Jmock will highlight badly designed communication protocols between
> object under test and its collaborators. On the other hand, frameworks
> like mockito by default ignore all calls between the object under test
> and it's mocked collaborator(s) and only verifies calls you explicitly
> specify.
There is, of course, a halfway ground to consider.  When I'm working in
.NET, I tend to use Rhino.Mocks.  This has the interesting facility that
if you call MockRepository.CreateMock to create your mock, you end up
with something that behaves like JMock does, but if you call
MockRepository.DynamicMock you end up with a stub implementation that
ignores unexpected calls, or you can use MockRepository.PartialMock when
mocking a concrete class to get a stub that passes calls to the original
implementation by default.  It's still a "set expectations before
running your code" style of interaction rather than the "verify what
happened after you've done it" style you use with Mockito, but it's a
little more flexible than JMock.

(The API's also a little cleaner, but that's because .NET allows a
cleaner API than Java does, largely due to having proper generic types)


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Neil Swingler]

I'm now using mockito after using jmock1.0 for a fair while. I do  
prefer the  brevity of mockito and doing verifications after  
invocation seems more natural than setting expectations in advance.  
Mockito may make a bad design a bit easier to test than jmock but  
setting up a lot of mocks is still a pain whichever framework you use.

- Neil




On 24 Oct 2009, at 12:53, Nat Pryce <nat.pryce@...> wrote:

> Hi James. The only comparison I know of is
> http://rrees.wordpress.com/2009/04/12/three-little-mockers/
>
> --Nat
>
> On Friday, October 23, 2009, James Mead <jamesmead44@...> wrote:
>> I'm interested in the pros & cons of jMock versus Mockito? Is the
>> choice just a matter of personal taste or are there more fundamental
>> issues I should be aware of?
>>
>> A comment [1] by Steve on Dan North's blog seems to suggest that  
>> jMock
>> will become syntactically noisy when your design is poor, but that
>> Mockito will stay syntactically quiet and allow you to get away it.
>> Have I understood that correctly? Can you elaborate? Do you have any
>> concrete examples?
>>
>> Thanks, James.
>>
>> [1] http://dannorth.net/2008/09/the-end-of-endotesting#comment-17523
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> --
> http://www.natpryce.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

Interesting. Maybe I'm just used to it, but I like having the protocol  
between neighbours made explicit, rather than implied.

S.

> I'm now using mockito after using jmock1.0 for a fair while. I do  
> prefer the  brevity of mockito and doing verifications after  
> invocation seems more natural than setting expectations in advance.  
> Mockito may make a bad design a bit easier to test than jmock but  
> setting up a lot of mocks is still a pain whichever framework you use.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

[phone]
M3P Limited.  http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

> There is, of course, a halfway ground to consider.  When I'm working  
> in .NET, I tend to use Rhino.Mocks.  This has the interesting  
> facility that if you call MockRepository.CreateMock to create your  
> mock, you end up with something that behaves like JMock does, but if  
> you call MockRepository.DynamicMock you end up with a stub  
> implementation that ignores unexpected calls, or you can use  
> MockRepository.PartialMock when mocking a concrete class to get a  
> stub that passes calls to the original implementation by default.  
> It's still a "set expectations before running your code" style of  
> interaction rather than the "verify what happened after you've done  
> it" style you use with Mockito, but it's a little more flexible than  
> JMock.

actually, jMock will do that with the allowing() clause.

> (The API's also a little cleaner, but that's because .NET allows a  
> cleaner API than Java does, largely due to having proper generic  
> types)

Last time I looked at it, I think Rhino could have had a much cleaner  
API. They have a lot more room to manoeuvre than we do.

S.

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

[phone]
M3P Limited.  http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2009/10/24 Neil Swingler <neil@...>:
> setting up a lot of mocks is still a pain whichever framework you use.

Our opinion (and jMock is 'opinionated software') is that is your
tests telling you that your object under test has too many
dependencies.  A test shouldn't create more than a handful of mocks.
Most tests I see create one or two.

--Nat

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Neil Swingler]

I agree Nat. I'm just trying to counter the opinion that mockito will  
hide a bad design.

- Neil

On 25 Oct 2009, at 15:00, Nat Pryce <nat.pryce@...> wrote:

> 2009/10/24 Neil Swingler <neil@...>:
>> setting up a lot of mocks is still a pain whichever framework you  
>> use.
>
> Our opinion (and jMock is 'opinionated software') is that is your
> tests telling you that your object under test has too many
> dependencies.  A test shouldn't create more than a handful of mocks.
> Most tests I see create one or two.
>
> --Nat
>
> --
> http://www.natpryce.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

Mockito won't hide that, I agree.

But it will hide complex inter-object protocols by, for example,
hiding that there are lots of get-calls between objects.

--Nat

2009/10/25 Neil Swingler <neil@...>:

> I agree Nat. I'm just trying to counter the opinion that mockito will hide a
> bad design.
>
> - Neil
>
> On 25 Oct 2009, at 15:00, Nat Pryce <nat.pryce@...> wrote:
>
>> 2009/10/24 Neil Swingler <neil@...>:
>>>
>>> setting up a lot of mocks is still a pain whichever framework you use.
>>
>> Our opinion (and jMock is 'opinionated software') is that is your
>> tests telling you that your object under test has too many
>> dependencies.  A test shouldn't create more than a handful of mocks.
>> Most tests I see create one or two.
>>
>> --Nat
>>
>> --
>> http://www.natpryce.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Rene Guenther]

Thats interesting. Normally that applies to our objects as well (one or two
mocks). But our main object (a financial document) has references to almost
all other objects. The documentManager is interacting with 10-15 other
managers (to be mocked). Would you recommend to split that manager? Maybe
you know of some pattern which would help simplify that manager?

Thanks
Rene

-----Ursprüngliche Nachricht-----
Von: Nat Pryce [mailto:nat.pryce@...]
Gesendet: Sonntag, 25. Oktober 2009 15:01
An: user@...
Betreff: Re: [jmock-user] Differences between jMock & Mockito

2009/10/24 Neil Swingler <neil@...>:
> setting up a lot of mocks is still a pain whichever framework you use.

Our opinion (and jMock is 'opinionated software') is that is your
tests telling you that your object under test has too many
dependencies.  A test shouldn't create more than a handful of mocks.
Most tests I see create one or two.

--Nat

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

2009/10/25 "Günther, Rene - Innflow AG" <rene.guenther@...>:
> Thats interesting. Normally that applies to our objects as well (one or two
> mocks). But our main object (a financial document) has references to almost
> all other objects. The documentManager is interacting with 10-15 other
> managers (to be mocked). Would you recommend to split that manager? Maybe
> you know of some pattern which would help simplify that manager?

I'd consider the fact that it has 10 to 15 dependencies a smell. Also
a smell is the fact that it has a vague word like "manager" in its
name.  I'd try to look at what its responsibilities are and divide it
up into objects that perform those responsibilities and are have more
evocative / concrete names.

Exactly what patterns I'd use I cannot say without knowing about the
system and domain.

--Nat

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

> I agree Nat. I'm just trying to counter the opinion that mockito  
> will hide a bad design.

I would love to see if using mockito/jmock actually has any effect on  
design. So far, I've peeked into as many as 3 codebases that use  
mockito and not been hugely impressed with 2 of them (no, I don't have  
any data for jmock).

It would be neat, for example, to run Keith's measure on different  
projects and see if there's a significant difference.

S.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Neil Swingler]

I have just given myself a 30 minute crash course in jmock2 by
converting one of jmock's very own unit tests to Mockito. OK I only
chose the first test but I think it gives a flavour of the differences.
The full compiling class is attached but here is the interesting bit.
Personally I would probably skip the verify steps in the mockito version
but kept them in for completeness.

    public void testLoadsObjectThatIsNotCachedWithJmock() {
        Mockery context = new Mockery() {{
            setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
        }};
        final Clock clock = context.mock(Clock.class);
        final ObjectLoader loader = context.mock(ObjectLoader.class,
"loader");
        ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
        context.checking(new Expectations() {{
            allowing (clock).time(); will(returnValue(loadTime));

            oneOf (loader).load("key1"); will(returnValue(VALUE1));
            oneOf (loader).load("key2"); will(returnValue(VALUE2));
        }});

        Object actualValue1 = cache.lookup("key1");
        Object actualValue2 = cache.lookup("key2");
       
        context.assertIsSatisfied();
        assertEquals("lookup with key1", VALUE1, actualValue1);
        assertEquals("lookup with key2", VALUE2, actualValue2);
    }

    public void testLoadsObjectThatIsNotCachedWithMockito() {
        Clock clock = mock(Clock.class);
        ObjectLoader loader = mock(ObjectLoader.class, "loader");
        ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);

        when(clock.time()).thenReturn(loadTime);
        when(loader.load(eq("key1"))).thenReturn(VALUE1);
        when(loader.load(eq("key2"))).thenReturn(VALUE2);

        Object actualValue1 = cache.lookup("key1");
        Object actualValue2 = cache.lookup("key2");
       
        verify(loader).load("key1");
        verify(loader).load("key2");
       
        verifyNoMoreInteractions(loader);
        assertEquals("lookup with key1", VALUE1, actualValue1);
        assertEquals("lookup with key2", VALUE2, actualValue2);
    }

- Neil

/*  Copyright (c) 2000-2004 jMock.org
 */
package org.jmock.example.timedcache;

import static org.mockito.Matchers.eq;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
import static org.mockito.Mockito.when;

import java.util.Calendar;
import java.util.Date;

import junit.framework.TestCase;

import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit3.JUnit3ErrorTranslator;


public class TimedCacheTests extends TestCase {
    private Date loadTime = time(1);
    final Object VALUE1 = "value1";
    final Object VALUE2 = "value2";

    public void testLoadsObjectThatIsNotCachedWithJmock() {
        Mockery context = new Mockery() {{
            setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
        }};
        final Clock clock = context.mock(Clock.class);
        final ObjectLoader loader = context.mock(ObjectLoader.class, "loader");
        ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
        context.checking(new Expectations() {{
            allowing (clock).time(); will(returnValue(loadTime));

            oneOf (loader).load("key1"); will(returnValue(VALUE1));
            oneOf (loader).load("key2"); will(returnValue(VALUE2));
        }});

        Object actualValue1 = cache.lookup("key1");
        Object actualValue2 = cache.lookup("key2");
       
        context.assertIsSatisfied();
        assertEquals("lookup with key1", VALUE1, actualValue1);
        assertEquals("lookup with key2", VALUE2, actualValue2);
    }

    public void testLoadsObjectThatIsNotCachedWithMockito() {
        Clock clock = mock(Clock.class);
        ObjectLoader loader = mock(ObjectLoader.class, "loader");
        ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);

        when(clock.time()).thenReturn(loadTime);
        when(loader.load(eq("key1"))).thenReturn(VALUE1);
        when(loader.load(eq("key2"))).thenReturn(VALUE2);

        Object actualValue1 = cache.lookup("key1");
        Object actualValue2 = cache.lookup("key2");
       
        verify(loader).load("key1");
        verify(loader).load("key2");
       
        verifyNoMoreInteractions(loader);
        assertEquals("lookup with key1", VALUE1, actualValue1);
        assertEquals("lookup with key2", VALUE2, actualValue2);
    }

    private Date time(int i) {
        Calendar calendar = Calendar.getInstance();
        calendar.clear();
        calendar.set(Calendar.DAY_OF_YEAR, i);
        return calendar.getTime();
    }
}


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

They look not too different apart from Mockito makes you duplicate
expectations a bit.

An interesting comparison might be a test that uses jMock's States
mechanism to control ordering and vary the behaviour of mocked calls.

--Nat

On Sunday, October 25, 2009, Neil Swingler <neil@...> wrote:

> I have just given myself a 30 minute crash course in jmock2 by converting one of jmock's very own unit tests to Mockito. OK I only chose the first test but I think it gives a flavour of the differences. The full compiling class is attached but here is the interesting bit. Personally I would probably skip the verify steps in the mockito version but kept them in for completeness.
>
>    public void testLoadsObjectThatIsNotCachedWithJmock() {
>        Mockery context = new Mockery() {{
>            setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);
>        }};
>        final Clock clock = context.mock(Clock.class);
>        final ObjectLoader loader = context.mock(ObjectLoader.class, "loader");
>        ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);
>
>        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
>        context.checking(new Expectations() {{
>            allowing (clock).time(); will(returnValue(loadTime));
>
>            oneOf (loader).load("key1"); will(returnValue(VALUE1));
>            oneOf (loader).load("key2"); will(returnValue(VALUE2));
>        }});
>
>        Object actualValue1 = cache.lookup("key1");
>        Object actualValue2 = cache.lookup("key2");
>              context.assertIsSatisfied();
>        assertEquals("lookup with key1", VALUE1, actualValue1);
>        assertEquals("lookup with key2", VALUE2, actualValue2);
>    }
>
>    public void testLoadsObjectThatIsNotCachedWithMockito() {
>        Clock clock = mock(Clock.class);
>        ObjectLoader loader = mock(ObjectLoader.class, "loader");
>        ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);
>        TimedCache cache = new TimedCache(loader, clock, reloadPolicy);
>
>        when(clock.time()).thenReturn(loadTime);
>        when(loader.load(eq("key1"))).thenReturn(VALUE1);
>        when(loader.load(eq("key2"))).thenReturn(VALUE2);
>
>        Object actualValue1 = cache.lookup("key1");
>        Object actualValue2 = cache.lookup("key2");
>              verify(loader).load("key1");
>        verify(loader).load("key2");
>              verifyNoMoreInteractions(loader);
>        assertEquals("lookup with key1", VALUE1, actualValue1);
>        assertEquals("lookup with key2", VALUE2, actualValue2);
>    }
>
> - Neil
>

--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Neil Swingler]

Well here the stub part is being separated from the expectation part. I

think this is not a bad thing. As I said I would personally delete the

verification calls as they duplicate the checking done by the asserts at

the end anyway. I just left them in to demonstrate mockito.



- Neil



On Mon, 26 Oct 2009 07:05:14 +0000, Nat Pryce <nat.pryce@...> wrote:

> They look not too different apart from Mockito makes you duplicate

> expectations a bit.

>

> An interesting comparison might be a test that uses jMock's States

> mechanism to control ordering and vary the behaviour of mocked calls.

>

> --Nat

>

> On Sunday, October 25, 2009, Neil Swingler <neil@...> wrote:

>> I have just given myself a 30 minute crash course in jmock2 by

converting

>> one of jmock's very own unit tests to Mockito. OK I only chose the first

>> test but I think it gives a flavour of the differences. The full

>> compiling class is attached but here is the interesting bit. Personally

I

>> would probably skip the verify steps in the mockito version but kept

them

>> in for completeness.

>>

>>    public void testLoadsObjectThatIsNotCachedWithJmock() {

>>        Mockery context = new Mockery() {{

>>           

>>  setExpectationErrorTranslator(JUnit3ErrorTranslator.INSTANCE);

>>        }};

>>        final Clock clock = context.mock(Clock.class);

>>        final ObjectLoader loader = context.mock(ObjectLoader.class,

>>  "loader");

>>        ReloadPolicy reloadPolicy = context.mock(ReloadPolicy.class);

>>

>>        TimedCache cache = new TimedCache(loader, clock,

reloadPolicy);

>>        context.checking(new Expectations() {{

>>            allowing (clock).time(); will(returnValue(loadTime));

>>

>>            oneOf (loader).load("key1"); will(returnValue(VALUE1));

>>            oneOf (loader).load("key2"); will(returnValue(VALUE2));

>>        }});

>>

>>        Object actualValue1 = cache.lookup("key1");

>>        Object actualValue2 = cache.lookup("key2");

>>              context.assertIsSatisfied();

>>        assertEquals("lookup with key1", VALUE1, actualValue1);

>>        assertEquals("lookup with key2", VALUE2, actualValue2);

>>    }

>>

>>    public void testLoadsObjectThatIsNotCachedWithMockito() {

>>        Clock clock = mock(Clock.class);

>>        ObjectLoader loader = mock(ObjectLoader.class, "loader");

>>        ReloadPolicy reloadPolicy = mock(ReloadPolicy.class);

>>        TimedCache cache = new TimedCache(loader, clock,

reloadPolicy);

>>

>>        when(clock.time()).thenReturn(loadTime);

>>        when(loader.load(eq("key1"))).thenReturn(VALUE1);

>>        when(loader.load(eq("key2"))).thenReturn(VALUE2);

>>

>>        Object actualValue1 = cache.lookup("key1");

>>        Object actualValue2 = cache.lookup("key2");

>>              verify(loader).load("key1");

>>        verify(loader).load("key2");

>>              verifyNoMoreInteractions(loader);

>>        assertEquals("lookup with key1", VALUE1, actualValue1);

>>        assertEquals("lookup with key2", VALUE2, actualValue2);

>>    }

>>

>> - Neil

>>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

With tests like this, there's not much difference, although both tests  
could be made more compact. It's mostly stubbing, since there's no  
external change in state. There's a bit of duplication in the mockito  
version for the verification but, as you point out, it's not  
interesting here. Even easymock could be made to work for these tests.

I think the differences (if any) will become more apparent when the  
code deals in more behaviour than values. Here's an example from the  
book (hope it doesn't get mangled by line-wrapping):

public class SniperLauncherTest {
   private final States auctionState = context.states("auction state")
                                              .startsAs("not joined");

   @Test public void addsNewSniperToCollectorAndThenJoinsAuction() {
     final String itemId = "item 123";
     context.checking(new Expectations() {{
       allowing(auctionHouse).auctionFor(itemId); will(returnValue
(auction));

       oneOf(sniperCollector).addSniper(with(sniperForItem(item)));
                                           when(auctionState.is("not  
joined"));      
       oneOf(auction).addAuctionEventListener(with(sniperForItem
(itemId)));
                                           when(auctionState.is("not  
joined"));
       one(auction).join(); then(auctionState.is("joined"));
     }});

     launcher.joinAuction(itemId);
   }
}

which describes the relationships between a "launcher", an "auction",  
and a "sniperCollector". This is about protocols between objects, not  
just method calls, and maps nicely onto a state-transition diagram we  
drew to describe these relationships. We don't need this all the time,  
but when we do, we really do.

S.

On 25 Oct 2009, at 23:56, Neil Swingler wrote:
> I have just given myself a 30 minute crash course in jmock2 by  
> converting one of jmock's very own unit tests to Mockito. OK I only  
> chose the first test but I think it gives a flavour of the  
> differences. The full compiling class is attached but here is the  
> interesting bit. Personally I would probably skip the verify steps  
> in the mockito version but kept them in for completeness.
> [...]

Steve Freeman

Winner of the Agile Alliance Gordon Pask award 2006
Book: http://www.growing-object-oriented-software.com

[phone]
M3P Limited.  http://www.m3p.co.uk
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Rick Fisk-2]

PowerMock works a bit like this. It allows you to create partial mocks
and to mock static objects. Unfortunately if you're testing spring
managers or controllers there are issues to workaround with bean
definitions. It has interfaces to mockito and EasyMock also.

Julian Hall wrote:

> isaiah perumalla wrote:
>> Jmock will highlight badly designed communication protocols between
>> object under test and its collaborators. On the other hand,
>> frameworks like mockito by default ignore all calls between the
>> object under test and it's mocked collaborator(s) and only verifies
>> calls you explicitly specify.
> There is, of course, a halfway ground to consider.  When I'm working
> in .NET, I tend to use Rhino.Mocks.  This has the interesting facility
> that if you call MockRepository.CreateMock to create your mock, you
> end up with something that behaves like JMock does, but if you call
> MockRepository.DynamicMock you end up with a stub implementation that
> ignores unexpected calls, or you can use MockRepository.PartialMock
> when mocking a concrete class to get a stub that passes calls to the
> original implementation by default.  It's still a "set expectations
> before running your code" style of interaction rather than the "verify
> what happened after you've done it" style you use with Mockito, but
> it's a little more flexible than JMock.
>
> (The API's also a little cleaner, but that's because .NET allows a
> cleaner API than Java does, largely due to having proper generic types)
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

> Julian Hall wrote:
>> isaiah perumalla wrote:
>>> Jmock will highlight badly designed communication protocols  
>>> between object under test and its collaborators. On the other  
>>> hand, frameworks like mockito by default ignore all calls between  
>>> the object under test and it's mocked collaborator(s) and only  
>>> verifies calls you explicitly specify.
>> There is, of course, a halfway ground to consider.  When I'm  
>> working in .NET, I tend to use Rhino.Mocks.  This has the  
>> interesting facility that if you call MockRepository.CreateMock to  
>> create your mock, you end up with something that behaves like JMock  
>> does, but if you call MockRepository.DynamicMock you end up with a  
>> stub implementation that ignores unexpected calls, or you can use  
>> MockRepository.PartialMock when mocking a concrete class to get a  
>> stub that passes calls to the original implementation by default.  
>> It's still a "set expectations before running your code" style of  
>> interaction rather than the "verify what happened after you've done  
>> it" style you use with Mockito, but it's a little more flexible  
>> than JMock.

Actually, JMock does the first two without have to choose when  
declaring the mock. The third is just a bad idea unless it's an  
emergency :)

S.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email