mockito in six easy examples

[Gojko Adzic]

if you're using tdd in java and not using mockito, it's time to change
your mock library. I’m fascinated by how easy it is to use, compared to
other things out there both in the Java and .NET world.

Have a look at http://gojko.net/2009/10/23/mockito-in-six-easy-examples/ 
and see for yourself.

--
gojko adzic
http://gojok.net

[Oliver Ferrigni-2]

I've used mocking libraries pretty extensively and while it can be nice to
have a mocking framework provide you permissive mocks, I find permissive
mocks make writing bad code easier.  This has been proven out in teams that
are using mockito where there are 70 line when statements, only 30 of which
actually matter in a test.

Is there a way to do strict mocks in mockito?

Oliver

On Fri, Oct 23, 2009 at 8:51 AM, Gojko Adzic <gojko-yahoolist@...>wrote:

>
>
> if you're using tdd in java and not using mockito, it's time to change
> your mock library. I’m fascinated by how easy it is to use, compared to
> other things out there both in the Java and .NET world.
>
> Have a look at http://gojko.net/2009/10/23/mockito-in-six-easy-examples/
> and see for yourself.
>
> --
> gojko adzic
> http://gojok.net
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:testdrivendevelopment-digest@...
    mailto:testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Srdjan Todorovic]

Hi there,

On 23/10/2009, Gojko Adzic <gojko-yahoolist@...> wrote:
> if you're using tdd in java and not using mockito, it's time to change
> your mock library. I’m fascinated by how easy it is to use, compared to
> other things out there both in the Java and .NET world.
>
> Have a look at http://gojko.net/2009/10/23/mockito-in-six-easy-examples/
> and see for yourself.

So a mock == a stub?

I think I understand how example 1 works - at any time i.next() is
called, where i is the mocked Iterator, then it will return things
that are specified by thenReturn() ?

What's with "@Test" ?

With example 2, what is actually being tested?

I may have other questions later - never looked at mocks before and
struggling to understand the need for them in some of your examples.

The Basematcher and @Override bits (overriding without creating a new
class type) seem like illegal syntax, but perhaps this is some form of
new Java functionality.

Regards,
Srdjan

[zdsbs]

>
> Is there a way to do strict mocks in mockito?
>


well you can use verifyNoMoreInteractions() which kind of turns it all into a strict mock.  And according to http://code.google.com/p/mockito/issues/detail?id=105 there will also be an only() method which you can use like so:
verify(dataAcceptor, only()).set(some good stuff);

-Zach


     

[Gojko Adzic]

having 40 out of 70 codes in a test that doesn't really matter for the
test is often a problem of not specifying tests precisely (checking for
too many things) or it can point to bad class design (too much setup
required). Rather than talking about abstract teams and something being
proven, can you send a couple of examples and then we can discuss them
on the list?

--
gojko adzic
http://gojko.net


Oliver Ferrigni wrote:

> I've used mocking libraries pretty extensively and while it can be nice to
> have a mocking framework provide you permissive mocks, I find permissive
> mocks make writing bad code easier.  This has been proven out in teams that
> are using mockito where there are 70 line when statements, only 30 of which
> actually matter in a test.
>
> Is there a way to do strict mocks in mockito?
>
> Oliver
>
> On Fri, Oct 23, 2009 at 8:51 AM, Gojko Adzic <gojko-yahoolist@...>wrote:
>
>>
>> if you're using tdd in java and not using mockito, it's time to change
>> your mock library. I�m fascinated by how easy it is to use, compared to
>> other things out there both in the Java and .NET world.
>>
>> Have a look at http://gojko.net/2009/10/23/mockito-in-six-easy-examples/
>> and see for yourself.
>>
>> --
>> gojko adzic
>> http://gojok.net
>>
>>  
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

[Oliver Ferrigni-2]

Gojko,

Example following is from the mockito documentation

  import static org.mockito.Mockito.*;

  List mock = mock(List.class);

  when(mock.get(0)).thenReturn("one");
  when(mock.get(1)).thenReturn("two");

  someCodeThatInteractsWithMock();

  verify(mock).clear();

What I would prefer is verifyEverythingHappenedOrFail().  This prevents the
mocking framework from enabling people from writing coupled code.

A very advanced mockist using the tool might write classes that interact
with very few collaborators, reducing the danger of not verifying every
collaborator.  That has not been the case for those people I've seen use
mockito.  Instead, there are many stubs, few verifications, and lots of
wasted code.

All that could just be a training problem and completely independent of the
mocking framework.

Oliver

On Fri, Oct 23, 2009 at 10:15 AM, Gojko Adzic <gojko-yahoolist@...>wrote:

>
>
>
> having 40 out of 70 codes in a test that doesn't really matter for the
> test is often a problem of not specifying tests precisely (checking for
> too many things) or it can point to bad class design (too much setup
> required). Rather than talking about abstract teams and something being
> proven, can you send a couple of examples and then we can discuss them
> on the list?
>
> --
> gojko adzic
> http://gojko.net
>
>
> Oliver Ferrigni wrote:
> > I've used mocking libraries pretty extensively and while it can be nice
> to
> > have a mocking framework provide you permissive mocks, I find permissive
> > mocks make writing bad code easier. This has been proven out in teams
> that
> > are using mockito where there are 70 line when statements, only 30 of
> which
> > actually matter in a test.
> >
> > Is there a way to do strict mocks in mockito?
> >
> > Oliver
> >
> > On Fri, Oct 23, 2009 at 8:51 AM, Gojko Adzic <gojko-yahoolist@...<gojko-yahoolist%40gojko.com>
> >wrote:
> >
> >>
> >> if you're using tdd in java and not using mockito, it's time to change
> >> your mock library. I�m fascinated by how easy it is to use, compared to
> >> other things out there both in the Java and .NET world.
> >>
> >> Have a look at
> http://gojko.net/2009/10/23/mockito-in-six-easy-examples/
> >> and see for yourself.
> >>
> >> --
> >> gojko adzic
> >> http://gojok.net
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>  
>

[Non-text portions of this message have been removed]

[Gojko Adzic]

documentation examples are used to demonstrate usage and aren't really
from real projects. I'd rather see that example of 70 lines where 40 are
not related to the test and discuss that.

I'm sure that I understood correctly what you suggest below. I'm not a
big fan of "verifyEverything" as that often verifies too much and
prevents people from changing the implementation. If the contract of
the method under test is to change the user's first name, I like to
verify just that rather than a whole sequence of events leading to the
change. Focusing on what rather than how leads to tests that are
shorter, clearer and much less fragile. IMHO, unit tests should allow us
to flesh out the interface and specify the contract of a class, not
presume implementation details.

gojko

Oliver Ferrigni wrote:

>  
>
> Gojko,
>
> Example following is from the mockito documentation
>
> import static org.mockito.Mockito.*;
>
> List mock = mock(List.class);
>
> when(mock.get(0)).thenReturn("one");
> when(mock.get(1)).thenReturn("two");
>
> someCodeThatInteractsWithMock();
>
> verify(mock).clear();
>
> What I would prefer is verifyEverythingHappenedOrFail(). This prevents the
> mocking framework from enabling people from writing coupled code.
>
> A very advanced mockist using the tool might write classes that interact
> with very few collaborators, reducing the danger of not verifying every
> collaborator. That has not been the case for those people I've seen use
> mockito. Instead, there are many stubs, few verifications, and lots of
> wasted code.
>
> All that could just be a training problem and completely independent of the
> mocking framework.
>
> Oliver
>
> On Fri, Oct 23, 2009 at 10:15 AM, Gojko Adzic <gojko-yahoolist@...
> <mailto:gojko-yahoolist%40gojko.com>>wrote:
>
>  >
>  >
>  >
>  > having 40 out of 70 codes in a test that doesn't really matter for the
>  > test is often a problem of not specifying tests precisely (checking for
>  > too many things) or it can point to bad class design (too much setup
>  > required). Rather than talking about abstract teams and something being
>  > proven, can you send a couple of examples and then we can discuss them
>  > on the list?
>  >
>  > --
>  > gojko adzic
>  > http://gojko.net <http://gojko.net>
>  >
>  >
>  > Oliver Ferrigni wrote:
>  > > I've used mocking libraries pretty extensively and while it can be nice
>  > to
>  > > have a mocking framework provide you permissive mocks, I find
> permissive
>  > > mocks make writing bad code easier. This has been proven out in teams
>  > that
>  > > are using mockito where there are 70 line when statements, only 30 of
>  > which
>  > > actually matter in a test.
>  > >
>  > > Is there a way to do strict mocks in mockito?
>  > >
>  > > Oliver
>  > >
>  > > On Fri, Oct 23, 2009 at 8:51 AM, Gojko Adzic
> <gojko-yahoolist@...
> <mailto:gojko-yahoolist%40gojko.com><gojko-yahoolist%40gojko.com>
>  > >wrote:
>  > >
>  > >>
>  > >> if you're using tdd in java and not using mockito, it's time to change
>  > >> your mock library. I�m fascinated by how easy it is to use,
> compared to
>  > >> other things out there both in the Java and .NET world.
>  > >>
>  > >> Have a look at
>  > http://gojko.net/2009/10/23/mockito-in-six-easy-examples/ 
> <http://gojko.net/2009/10/23/mockito-in-six-easy-examples/>
>  > >> and see for yourself.
>  > >>
>  > >> --
>  > >> gojko adzic
>  > >> http://gojok.net <http://gojok.net>
>  > >>
>  > >>
>  > >>
>  > >
>  > >
>  > > [Non-text portions of this message have been removed]
>  > >
>  > >
>  > >
>  > > ------------------------------------
>  > >
>  > > Yahoo! Groups Links
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
>  >
>  >
>
> [Non-text portions of this message have been removed]
>
>

[Gojko Adzic]

>
> I'm sure that I understood correctly what you suggest below. I'm not a

I wanted to write "I'm not sure" instead of "I'm sure"

gojko

[Dale Emery]

Hi Oliver,

Example following is from the mockito documentation

>
>  import static org.mockito.Mockito.*;
>
>  List mock = mock(List.class);
>
>  when(mock.get(0)).thenReturn("one");
>  when(mock.get(1)).thenReturn("two");
>
>  someCodeThatInteractsWithMock();
>
>  verify(mock).clear();
>
> What I would prefer is verifyEverythingHappenedOrFail().  This prevents the
> mocking framework from enabling people from writing coupled code.
>

Can you give an example of the kind of bad code this allows in
someCodeThatInteractsWithMock()?

For the record, I love mockito's simplicity. I tend to write software solo
these days, and I haven't noticed the kinds of problems you're concerned
about. I won't say I'm not creating the problems, but if I am, I'm not
noticing them. So I'm hoping your examples will help me to understand the
kinds of problems you've seen.

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

[Gojko Adzic]

Srdjan Todorovic wrote:

>  
>
> Hi there,
>
> On 23/10/2009, Gojko Adzic <gojko-yahoolist@...
> <mailto:gojko-yahoolist%40gojko.com>> wrote:
>  > if you're using tdd in java and not using mockito, it's time to change
>  > your mock library. I’m fascinated by how easy it is to use, compared to
>  > other things out there both in the Java and .NET world.
>  >
>  > Have a look at
> http://gojko.net/2009/10/23/mockito-in-six-easy-examples/ 
> <http://gojko.net/2009/10/23/mockito-in-six-easy-examples/>
>  > and see for yourself.
>
> So a mock == a stub?

mockito doesn't differentiate between mocks and stubs. the main web site
of the library actually claims that this is a test spy library. it's up
to you to decide whether you use it as a mock or a stub.

> I think I understand how example 1 works - at any time i.next() is
> called, where i is the mocked Iterator, then it will return things
> that are specified by thenReturn() ?

yes

> What's with "@Test" ?

see junit 4 documentation

that comparison of c and "Test" returns -1 (demonstrating stubbing a
method with parameters)


> The Basematcher and @Override bits (overriding without creating a new
> class type) seem like illegal syntax, but perhaps this is some form of
> new Java functionality.

nope, it's a simple anonymous inner class - the syntax has been there
for years.

--
gojko adzic
http://gojko.net

[Dale Emery]

Hi Zach,

well you can use verifyNoMoreInteractions() which kind of turns it all into
> a strict mock.


Yeah, that's half of strictness: Make sure nothing else was called.

It doesn't seem to implement the other half of strictness: Make sure
everything was called.

I haven't felt a need for strictness, and I'm not sure why.

My guess is this: The UUT calls two kinds of methods on its collaborators:
queries and actions (e.g. commands, notifications, ...). I'm sure there's a
better word than "action" here, but I can't think of it.

In general, I don't test query calls directly, because I don't think of the
UUT as having a /responsibility/ to make that call. If the UUT ends up with
the right data, I don't care (sorta) how it gets the data. Of course, I do
set up the test so that there's only one place the UUT can get the data
(i.e. from the stubbed collaborator). But most of the time, the identity of
the source of the data is an implementation detail for the UUT, and not part
of the essence of its responsibilities. So I set up those queries using
when(), and don't worry about strictness for those.

That's my general approach, and there are exceptions. Sometimes--very
rarely--I give the UUT the /responsibility/ to get a particular bit of data
from a particular collaborator. But in those cases, I test that
responsibility directly, in a test of its own, using verify(), and never in
the same test in which I verify() other calls.

So the strong principles I use are these:
- Verify every responsibility I've allocated to the UUT.
- Verify nothing else--because all else is implementation detail.
- Verify each responsibility separately--i.e. in separate tests.

Under what conditions would the UUT have a definite responsibility /not/ to
call some method? There are protocols with that kind of responsibility. I
can't think of a good example at the moment, so I'll offer a lame one:
Disallow invoking some action until the user has logged in. Mockito's
verifyNoMoreInteractions() can handle that.

I can't think of a time when I wanted to verify that the UUT refrained from
calling a /particular/ method, though I can imagine protocols with that
responsibility.

If I remember right (it's been about a year since I used mockito), mockito
also does not verify the order in which calls were made. I can't recall
having a need for that, though, again, I can imagine protocols with that
responsibility.

Dale

--
Dale Emery
Consultant to software teams and leaders
Web: http://dhemery.com
Weblog: http://cwd.dhemery.com


[Non-text portions of this message have been removed]

[Roy Osherove]

I've found that strict mocks actually lead to very brittle tests. can you
please explain how permissive mocks are bad?

On Fri, Oct 23, 2009 at 4:16 PM, Oliver Ferrigni <thesolonius@...>wrote:

> I've used mocking libraries pretty extensively and while it can be nice to
> have a mocking framework provide you permissive mocks, I find permissive
> mocks make writing bad code easier.  This has been proven out in teams that
> are using mockito where there are 70 line when statements, only 30 of which
> actually matter in a test.
>
> Is there a way to do strict mocks in mockito?
>
> Oliver
>
> On Fri, Oct 23, 2009 at 8:51 AM, Gojko Adzic <gojko-yahoolist@...
> >wrote:
>
> >
> >
> > if you're using tdd in java and not using mockito, it's time to change
> > your mock library. I’m fascinated by how easy it is to use, compared to
> > other things out there both in the Java and .NET world.
> >
> > Have a look at http://gojko.net/2009/10/23/mockito-in-six-easy-examples/
> > and see for yourself.
> >
> > --
> > gojko adzic
> > http://gojok.net
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
[phone] (GMT+2)


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:testdrivendevelopment-digest@...
    mailto:testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

[Steve Freeman-4]

We cover some of these situations in our book.

On 23 Oct 2009, at 18:45, Dale Emery wrote:
>
> My guess is this: The UUT calls two kinds of methods on its collaborators:
> queries and actions (e.g. commands, notifications, ...). I'm sure there's a
> better word than "action" here, but I can't think of it.

> In general, I don't test query calls directly, because I don't think of the
> [...]
> when(), and don't worry about strictness for those.

Agreed. We have a heuristic, "Stub Queries, Mock Actions"

> Under what conditions would the UUT have a definite responsibility /not/ to
> call some method? There are protocols with that kind of responsibility. I
> can't think of a good example at the moment, so I'll offer a lame one:
> Disallow invoking some action until the user has logged in. Mockito's
> verifyNoMoreInteractions() can handle that.

I want to know later, when I've changed some other part of the code, that I've not triggered an unexpected action on a collaborator.

> I can't think of a time when I wanted to verify that the UUT refrained from
> calling a /particular/ method, though I can imagine protocols with that
> responsibility.

Sometimes I write a never() clause into the test to show the reader what my intentions are: in /this/ case it happens, in /that/ case I'm doing something else. It's not necessary computationally, but is a means of expression.

> If I remember right (it's been about a year since I used mockito), mockito
> also does not verify the order in which calls were made. I can't recall
> having a need for that, though, again, I can imagine protocols with that
> responsibility.

it's not impossible. Consider sending a message before closing a connection. In our worked example, we implement a state machine, so we want to show that some transitions happen in the right order.

S.

Steve Freeman
http://www.mockobjects.com
http://www.growing-object-oriented-software.com

Winner of the Agile Alliance Gordon Pask award 2006

[Steve Freeman-4]

On 23 Oct 2009, at 17:17, Gojko Adzic wrote:
> documentation examples are used to demonstrate usage and aren't really
> from real projects.

Please get this fixed as soon as possible. Unrepresentative examples (consider the whole of MSDN) are like CFCs, they pollute the atmosphere with examples of bad design that take years to remove. In the example here, these are queries that should be stubbed and not asserted.

In our world (jMock), we can verify everything because we only set expectations where it matters, everything else is allowed through. The unfortunate legacy of the wording in easymock is that lots of people try to expect everything, leading to the brittle code that everyone complains about.

S.

> I'm sure that I understood correctly what you suggest below. I'm not a
> big fan of "verifyEverything" as that often verifies too much and
> prevents people from changing the implementation. If the contract of
> the method under test is to change the user's first name, I like to
> verify just that rather than a whole sequence of events leading to the
> change. Focusing on what rather than how leads to tests that are
> shorter, clearer and much less fragile. IMHO, unit tests should allow us
> to flesh out the interface and specify the contract of a class, not
> presume implementation details.
>
> gojko
>
> Oliver Ferrigni wrote:
>>
>>
>> Gojko,
>>
>> Example following is from the mockito documentation
>>
>> import static org.mockito.Mockito.*;
>>
>> List mock = mock(List.class);
>>
>> when(mock.get(0)).thenReturn("one");
>> when(mock.get(1)).thenReturn("two");
>>
>> someCodeThatInteractsWithMock();
>>
>> verify(mock).clear();

Steve Freeman
http://www.mockobjects.com
http://www.growing-object-oriented-software.com

Winner of the Agile Alliance Gordon Pask award 2006

[Carlos Ble-2]

2009/11/10 Steve Freeman <smgfreeman@...>

>
>
> We cover some of these situations in our book.
>
>
> On 23 Oct 2009, at 18:45, Dale Emery wrote:
> >
> > My guess is this: The UUT calls two kinds of methods on its
> collaborators:
> > queries and actions (e.g. commands, notifications, ...). I'm sure there's
> a
> > better word than "action" here, but I can't think of it.
>
> > In general, I don't test query calls directly, because I don't think of
> the
> > [...]
>
> > when(), and don't worry about strictness for those.
>
> Agreed. We have a heuristic, "Stub Queries, Mock Actions"
>

Great sentence Steve. I use it in my Spanish TDD book-in-progress  (credits
to you are in the book of course)

>
> > Under what conditions would the UUT have a definite responsibility /not/
> to
> > call some method? There are protocols with that kind of responsibility. I
> > can't think of a good example at the moment, so I'll offer a lame one:
> > Disallow invoking some action until the user has logged in. Mockito's
> > verifyNoMoreInteractions() can handle that.
>
> I want to know later, when I've changed some other part of the code, that
> I've not triggered an unexpected action on a collaborator.
>
> > I can't think of a time when I wanted to verify that the UUT refrained
> from
> > calling a /particular/ method, though I can imagine protocols with that
> > responsibility.
>
> Sometimes I write a never() clause into the test to show the reader what my
> intentions are: in /this/ case it happens, in /that/ case I'm doing
> something else. It's not necessary computationally, but is a means of
> expression.
>
>
> > If I remember right (it's been about a year since I used mockito),
> mockito
> > also does not verify the order in which calls were made. I can't recall
> > having a need for that, though, again, I can imagine protocols with that
> > responsibility.
>
> it's not impossible. Consider sending a message before closing a
> connection. In our worked example, we implement a state machine, so we want
> to show that some transitions happen in the right order.
>

You might need a strict mock for performance reasons too: say you need to
ensure that the SUT hits the remote service just once in the whole process.
Haven't try mockito yet (by the way the name is terrible in Spanish: little
snot) but I appreciate Rhino.Mocks' features: GenerateMock and
GenerateStrictMock. With the methods others have said here, I get the
feeling mockit offers pretty much the same capabilities.

Thanks Gojko

>
> S.
>
> Steve Freeman
> http://www.mockobjects.com
> http://www.growing-object-oriented-software.com
>
> Winner of the Agile Alliance Gordon Pask award 2006
>
>  
>

--
Carlos Ble
www.iExpertos.com
www.carlosble.com


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest@...
    testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/