feature request - mockito stubs to return "intelligent" null to avoid NPEs

[Dan North]

Hi folks.

So far as a coaching tool mockito is streets ahead of jmock/easymock.
Here's a thing though - as I add dependencies to a class I find an
earlier test might fail with a NPE.

What happens is I refactor the constructor MyFarm() to MyFarm(Cowshed
cowshed), passing in a mock for cowshed. Then myFarm might do this:

Cow cow = cowshed.findCow();
// ...
cow.milk(); // uh oh - NPE on null returned from cowshed stub

It's not immediately obvious where this NPE came from - which is one
of the risks of verify-afterwards. For people new to TDD this can be
disconcerting (it's happened to me several times now). I'm wondering
if there isn't some sort of "intelligent" dynamic proxy you could
return from any unstubbed method that would fail if any method is
called on it (MethodCalledOnUnstubbedObjectException or something). It
could show a stack trace of the line where the object was (not)
created - the cowshed.findCow() method in this example.

The downside would be that cowshed.findCow() == null would no longer
be true for a default mock cowshed.

Cheers,
Dan

[Per Lundholm]

Or if there was some way to define the null object for a class. A
null
object lets you continue executing since it is a valid object.

Like this
import static org.mockito.Mockito.null;

null(Cow.class); // States that we wish an empty object should be
returned
whenever a Cow object is to be returned, instead of null.

or

null(Cow.class, new Cow()); // Return the given object instead of
null

/Per

[Dan North]

That's what I'm thinking. I'm going to spike a few things and report back. Maybe :-o

2008/9/23 Per Lundholm <per.lu...@gmail.com>

[Per Lundholm]

That's the spirit!

Good Luck!

/Per

[szczepiq]

Interesting case.

I'm throwing another potential solution: make default stubs return
mocks instead of nulls. This option can be spiked with a help of
experimental configuration API:
http://mockito.googlecode.com/svn/branches/1.5/javadoc/org/mockito/configuration/experimental/ConfigurationSupport.html
You can try it and tell us how it works.

Also: tell, don't ask :-)

Szczepan Faber

On Tue, Sep 23, 2008 at 8:13 PM, Dan North <tast...@gmail.com> wrote:

[Per Lundholm]

In theory, this seems great. The example looks generic enough to be included in the library as utility.

/Per

[Dan North]

That might be a good hook. The code I'm wanting to write in my test is something like:

import static org.mockito.Mockito.*; // includes org.mockito.Stubbers.*
...

Cowshed cowshed1 = mock(Cowshed.class, WITH_SMART_NULLS);   // like the ones I described
Cowshed cowshed2 = mock(Cowshed.class, WITH_REGULAR_NULLS); // you know, like null :)
Cowshed cowshed3 = mock(Cowshed.class);          // defaults to WITH_REGULAR_NULLS
Cowshed cowshed4 = mock(Cowshed.class, STRICT);  // throws exception on any unstubbed call

Something like that anyway. And I can implement my own custom Stubber with a similar interface to your configurator for dealing with legacy code. Probably by extending a BaseStubber abstract class.

Cheers,
Dan

2008/9/23 szczepiq <szcz...@gmail.com>

[szczepiq]

> Cowshed cowshed4 = mock(Cowshed.class, STRICT); // throws exception on any
> unstubbed call

For above one you might need a decent 'expect' api... I wonder where
is it going... Single library with both spying and mocking API? :)

I started thinking about the case you're coming from:

>It's not immediately obvious where this NPE came from - which is one of the risks of verify-afterwards.

I'm inclined to disagree - it's pretty obvious where the NPE comes
from. After all, I added this dependency + the logic that works on the
return value. Unless the code is really big & sucky :) For me, your
case is more like a proof that "tell don't ask" is a neat practice.

I'm really interested in the results of your spikes!

Cheers,
Szczepan Faber

[Dan North]

> Cowshed cowshed4 = mock(Cowshed.class, STRICT);  // throws exception on any
> unstubbed call

For above one you might need a decent 'expect' api... I wonder where
is it going... Single library with both spying and mocking API? :)

Nonononononono! The beauty of mockito is that I don't have to worry about all that prior expectation crap. I just want a general strategy around stubbing behaviour. In fact it feels like those three (strict, smart and normal) pretty much cover most usual cases.

As you said, the bigger win is when you're cutting into a legacy codebase with ask-don't-tell all over the place.

>It's not immediately obvious where this NPE came from - which is one of the risks of verify-afterwards.

I'm inclined to disagree - it's pretty obvious where the NPE comes
from.

For you and me, sure. And with experience it becomes more obvious. I'm talking about people taking their first steps into TDD and mocking. This sort of "non-obvious failure can be (and has been) quite a distraction. One of my guys went back to EasyMock because of this. I'm gradually coaxing him back though :)
 

After all, I added this dependency + the logic that works on the
return value. Unless the code is really big & sucky :) For me, your
case is more like a proof that "tell don't ask" is a neat practice.

I'm really interested in the results of your spikes!

I'll keep you posted. So when are you migrating mockito to a mercurial repository? ;)

Cheers,
Szczepan Faber

Cheers,
Dan

[szczepiq]

>One of my guys went back to EasyMock because of this. I'm gradually coaxing him back though :)

Hmmm, very interesting. I'm dying to know about cases of people going
back classical mocking and the reasons behind it. Make sure you get
his story before you burn the heretic... :) Seriously though, let us
know what happened eventually and if he is really happy with easymock.

>strict, smart and normal

I like the idea. You think different styles would be applicable for
different applications? E.g. new code => normal, legacy code =>
strict/smart?

> I'll keep you posted. So when are you migrating mockito to a mercurial repository? ;)

Yeah, I've gotta do it. I'm so tired with svn. I moved mockito-python
to hg and I smile very often now. I would still like to have some
syncing process (hg->svn) because I don't want to lose potential
contributors (java guys are so used to svn).

cheers,
Szczepan Faber

[Roberto]

On 25 Sep, 15:35, szczepiq <szcze...@gmail.com> wrote:
> Yeah, I've gotta do it. I'm so tired with svn. I moved mockito-python
> to hg and I smile very often now. I would still like to have some
> syncing process (hg->svn) because I don't want to lose potential
> contributors (java guys are so used to svn).

Nah, not this java guy! I say switch to hg!

Roberto

[Dan North]

Just for giggles I ran an hg convert into here: http://www.bitbucket.org/tastapod/mockito/

My intention is to keep it up-to-date based on the svn revisions, so if you just want to hack on stuff you can clone the repository. I think it will make it easier to submit patches. It will for me at least :)

Please don't take this as a canonical or even officially-endorsed url. (For a start it is only tracking trunk history - it doesn't contain any branches or tags, although that would be possible too.)

For anyone else wanting to play with hg convert, you should unzip the attached shamap file (which tells hg convert which svn revisions have already been converted) and drop it in your .hg directory.

Cheers,
Dan

2008/9/27 Roberto <robert...@gmail.com>

[szczepiq]

Ok, cool.

How long did the convert take? I'm wondering how fast is hg convert.

cheers,
Szczepan

[Dan North]

It depends on the network connection. I left it running overnight (!) for the full thing. If you can get onto the actual server box apparently it's super-fast from a file:// repository. Over http it's not the fastest.

Cheers,
Dan

2008/9/29 szczepiq <szcz...@gmail.com>

[Dan North]

So I took a stab at the smart nulls thing. Attached is the output of svn diff against r939. I haven't used svn diff to create a patch file before so I don't know how to apply the patch! Failing that I've also attached a mercurial diff that should be a bit more robust. Let me know if a) you can get either of them to work (!) and b) you like the idea. There are also tests and examples.

Cheers,
Dan

2008/9/29 Dan North <tast...@gmail.com>

[szczepiq]

Cool! I'll definitely give it a go. I think I'm gonna just get it from
bitbucket first. Just after I finish off the presentation for tomorrow
JDD'08 :)

Szczepan Faber

[Dan North]

I'll try to put the changeset into the bitbucket repo as a named branch. Wish me luck :)

Have fun with your presentation.

Oh, and Erik Doernenburg and I ran a one-day TDD tutorial at JAOO using JUnit 4 and Mockito a couple of weeks ago which went really well. They totally got mocking and apparently that's unusual compared to the other times Erik has run the course. (This was the first time using Mockito, on previous occasions he's used JMock.)

Cheers,
Dan

2008/10/15 szczepiq <szcz...@gmail.com>

[szczepiq]

Cool, thanks for the info. I looked it up on the jaoo agenda
(http://jaoo.dk/aarhus-2008/presentation/Test+Driven+Development).
It's written there that you've used jmock when you actually have used
mockito. Cheaters :)

Szczepan

[Dan North]

It was a "late substitution". We decided during the main conference that we should use JUnit 4 and Mockito because we think they are the future of TDD and mocking in Java ;)

2008/10/15 szczepiq <szcz...@gmail.com>

[Igor Czechowski]

I've uploaded the svn patch into Rietveld. The link is
http://codereview.appspot.com/7301

Cheers,
Igor

[szczepiq]

I played with this a bit (not yet merged to trunk, though). I think
it's way cooler to get "Unstubbed method was invoked here" instead of
NPE.

1. I'm slowly thinking about making SMART_NULLS a default behavior of any mock.
2. Another thing to discuss is how to approach collections - return
empty collections or SMART_NULLS (I'm voting for empty collections).
3. Does it make sense to keep variants like SMART_NULLS / MOCKS /
NULLS if the default behavior will be SMART_NULLS?

Cheers,
Szczepan Faber

[Dan North]

Hi Szczepan.

2008/10/18 szczepiq <szcz...@gmail.com>

I played with this a bit (not yet merged to trunk, though). I think
it's way cooler to get "Unstubbed method was invoked here" instead of
NPE.

1. I'm slowly thinking about making SMART_NULLS a default behavior of any mock.

Sweet :)

2. Another thing to discuss is how to approach collections - return
empty collections or SMART_NULLS (I'm voting for empty collections).

Ah yeah. When I wrote the Null Object implementation for proxytoys we decided to use the "null" implementation of Collections (e.g. EMPTY_LIST), Strings ("") and arrays (Foo[0]). I think that would be more intuitive behaviour here too. If you don't need to know you shouldn't have to (so if your code iterates over an array it should happily ignore a zero-length array).

3. Does it make sense to keep variants like SMART_NULLS / MOCKS /
NULLS if the default behavior will be SMART_NULLS?

I would keep them around as a transitional thing - of course it's up to you :)

[szczepiq]

Yeah, default returns for strings and arrays should have better "null"
implementation in mockito. Better nulls + SMART_NULLS == version 2.0
because this stuff is not fully backwards compatible. I'm going to
release 1.6 soon (maybe even today) but it is going to have the
bugfixes and a bit of syntax change - without the new shiny nulls yet.

Cheers,
Szczepan Faber

[Dan North]

Take a look at the implementation of Null.Object() in proxytoys - it shows the hoops we jumped through for Java pre-generics - there's a lot more to null objects in java than you might think. There might be some stuff you can mine for the mockito nulls.

Cheers,
Dan

ps. In ruby you can get most of a null object implementation with: class NullObject; def method_missing self; end; end :)

2008/10/19 szczepiq <szcz...@gmail.com>

[szczepiq]

I merged the smart nulls feature into the trunk. It will change a bit,
for example it will use cglib to generate smart nulls, etc.

Cheers,
Szczepan Faber

[Dan North]

2008/10/30 szczepiq <szcz...@gmail.com>

I merged the smart nulls feature into the trunk.

Sweet :)
 

It will change a bit,
for example it will use cglib to generate smart nulls, etc.

It already does! It uses the cglib Proxy & InvocationHandler so it looks just like java.lang.reflect but works on concrete classes.

Cheers,
Dan

[szczepiq]

>It already does! It uses the cglib Proxy & InvocationHandler so it looks just like java.lang.reflect but works on concrete classes.

Hmmm, It complained when I tried with concrete class.

Nevermind though, I have a feeling that there is some proxy creation
logic in the codebase already :)

Cheers,
Szczepan

[Dan North]

Is it checked in as is? If so I'll pull down the latest on trunk and have a play.

Cheers,
Dan

2008/10/31 szczepiq <szcz...@gmail.com>

[Gili Tzabari]

Correct me if I'm wrong but here is the behavior I'm expecting:

If a test invokes an unstubbed method on a mock object:
- If the method returns non-Collection throw an exception
- If the method returns a Collection then return a special Mockito
implementation that implements these rules (that is, throws an exception
if the method returns a non-collection itself)

Gili

Dan North wrote:
> Is it checked in as is? If so I'll pull down the latest on trunk and
> have a play.
>
> Cheers,
> Dan
>

> 2008/10/31 szczepiq <szcz...@gmail.com <mailto:szcz...@gmail.com>>

>
>
> >It already does! It uses the cglib Proxy & InvocationHandler so it
> looks just like java.lang.reflect but works on concrete classes.
>
> Hmmm, It complained when I tried with concrete class.
>
> Nevermind though, I have a feeling that there is some proxy creation
> logic in the codebase already :)
>
> Cheers,
> Szczepan
>
> On Fri, Oct 31, 2008 at 12:06 PM, Dan North <tast...@gmail.com

> <mailto:tast...@gmail.com>> wrote:
> > 2008/10/30 szczepiq <szcz...@gmail.com <mailto:szcz...@gmail.com>>

> <mailto:szcz...@gmail.com>>

> >> >>>>
> >> >>>> Cool, thanks for the info. I looked it up on the jaoo agenda
> >> >>>>
> (http://jaoo.dk/aarhus-2008/presentation/Test+Driven+Development).
> >> >>>> It's written there that you've used jmock when you actually
> have used
> >> >>>> mockito. Cheaters :)
> >> >>>>
> >> >>>> Szczepan
> >> >>>>
> >> >>>> On Wed, Oct 15, 2008 at 9:40 PM, Dan North

> <tast...@gmail.com <mailto:tast...@gmail.com>>

> >> >>>> wrote:
> >> >>>> > I'll try to put the changeset into the bitbucket repo as
> a named
> >> >>>> > branch.
> >> >>>> > Wish me luck :)
> >> >>>> >
> >> >>>> > Have fun with your presentation.
> >> >>>> >
> >> >>>> > Oh, and Erik Doernenburg and I ran a one-day TDD tutorial
> at JAOO
> >> >>>> > using
> >> >>>> > JUnit 4 and Mockito a couple of weeks ago which went
> really well.
> >> >>>> > They
> >> >>>> > totally got mocking and apparently that's unusual
> compared to the
> >> >>>> > other
> >> >>>> > times Erik has run the course. (This was the first time using
> >> >>>> > Mockito,
> >> >>>> > on
> >> >>>> > previous occasions he's used JMock.)
> >> >>>> >
> >> >>>> > Cheers,
> >> >>>> > Dan
> >> >>>> >
> >> >>>> >
> >> >>>> > 2008/10/15 szczepiq <szcz...@gmail.com

> <mailto:szcz...@gmail.com>>

> >> >>>> >>
> >> >>>> >> Cool! I'll definitely give it a go. I think I'm gonna
> just get it
> >> >>>> >> from
> >> >>>> >> bitbucket first. Just after I finish off the
> presentation for
> >> >>>> >> tomorrow
> >> >>>> >> JDD'08 :)
> >> >>>> >>
> >> >>>> >> Szczepan Faber
> >> >>>> >>
> >> >>>> >> On Wed, Oct 15, 2008 at 8:30 PM, Dan North

> <tast...@gmail.com <mailto:tast...@gmail.com>>

> <mailto:tast...@gmail.com>>

> >> >>>> >> >>
> >> >>>> >> >> It depends on the network connection. I left it running
> >> >>>> >> >> overnight
> >> >>>> >> >> (!)
> >> >>>> >> >> for
> >> >>>> >> >> the full thing. If you can get onto the actual server box
> >> >>>> >> >> apparently
> >> >>>> >> >> it's
> >> >>>> >> >> super-fast from a file:// repository. Over http it's
> not the
> >> >>>> >> >> fastest.
> >> >>>> >> >>
> >> >>>> >> >> Cheers,
> >> >>>> >> >> Dan
> >> >>>> >> >>
> >> >>>> >> >>
> >> >>>> >> >> 2008/9/29 szczepiq <szcz...@gmail.com

> <mailto:szcz...@gmail.com>>

> >> >>>> >> >>>
> >> >>>> >> >>> Ok, cool.
> >> >>>> >> >>>
> >> >>>> >> >>> How long did the convert take? I'm wondering how
> fast is hg
> >> >>>> >> >>> convert.
> >> >>>> >> >>>
> >> >>>> >> >>> cheers,
> >> >>>> >> >>> Szczepan
> >> >>>> >> >>>
> >> >>>> >> >>> On Mon, Sep 29, 2008 at 9:59 AM, Dan North

> >> >>>> >> >>> <tast...@gmail.com <mailto:tast...@gmail.com>>

> <mailto:robert...@gmail.com>>

> >> >>>> >> >>> >>
> >> >>>> >> >>> >> On 25 Sep, 15:35, szczepiq <szcze...@gmail.com

[szczepiq]

>Correct me if I'm wrong but here is the behavior I'm expecting:

Existing functionality has not changed. There is an additional method
on Mockito class that allows you to create mock with different return
values strategy. The interface might change a bit.

Cheers,
Szczepan Faber

[Gili Tzabari]

Regardless, does it implement the behavior I mentioned or does it work
differently?

Gili

[szczepiq]

It works differently. When smart nulls are used then the default
return value is a SmartNull (or a primitive value). It has nothing to
do with collections. Note that this interface may change, also the way
smart nulls strategy works might also change.

Cheers,
Szczepan Faber

[szczepiq]

I'm thinking of changing SmartNullReturnValues a bit. Currently, it:
- returns primitive value
- returns SmartNull
- throws exception when SmartNull cannot be created (e.g. the
returned type is final)

How about this:
- returns primitive value
- returns "null object" of certain types, eg: empty collections,
zeros for Integers, etc.
- returns SmartNull
- returns null when SmartNull cannot be created

Dan, Per, anyone interested, what do you think? I can lay down my
reasoning but I want to know your opinions first.

Cheers,
Szczepan Faber

[Gili Tzabari]

I don't understand the benefit of this approach. Don't you want the
test code to break immediately when someone tries using an unstubbed
method? Isn't that the implicit assumption behind your stub() or
verify() blog article?

Gili

[Per Lundholm]

No, you don't want that. Most of all, you don't want a NullPointerException. It is just confusing.

/Per

[Gili Tzabari]

Setting aside for a second I potentially disagree with you, what are
you saying you *do* want? :)

Gili

> <mailto:szcz...@gmail.com> <mailto:szcz...@gmail.com

> <mailto:szcz...@gmail.com>>>
> >>>>>
> >>>>>
> >>>>> >It already does! It uses the cglib Proxy &
> InvocationHandler so it
> >>>>> looks just like java.lang.reflect but works on concrete
> classes.
> >>>>>
> >>>>> Hmmm, It complained when I tried with concrete class.
> >>>>>
> >>>>> Nevermind though, I have a feeling that there is some
> proxy creation
> >>>>> logic in the codebase already :)
> >>>>>
> >>>>> Cheers,
> >>>>> Szczepan
> >>>>>
> >>>>> On Fri, Oct 31, 2008 at 12:06 PM, Dan North
> <tast...@gmail.com <mailto:tast...@gmail.com>

> >>>>> <mailto:tast...@gmail.com <mailto:tast...@gmail.com>>>
> wrote:
> >>>>> > 2008/10/30 szczepiq <szcz...@gmail.com
> <mailto:szcz...@gmail.com> <mailto:szcz...@gmail.com

> <mailto:szcz...@gmail.com>>>
> >>>>> >>
> >>>>> >> I merged the smart nulls feature into the trunk.
> >>>>> >
> >>>>> > Sweet :)
> >>>>> >
> >>>>> >>
> >>>>> >> It will change a bit,
> >>>>> >> for example it will use cglib to generate smart
> nulls, etc.
> >>>>> >
> >>>>> > It already does! It uses the cglib Proxy &
> InvocationHandler so
> >>>>> it looks
> >>>>> > just like java.lang.reflect but works on concrete classes.
> >>>>> >
> >>>>> > Cheers,
> >>>>> > Dan
> >>>>> >
> >>>>> >
> >>>>> >> Cheers,
> >>>>> >> Szczepan Faber
> >>>>> >>
> >>>>> >> On Sat, Oct 18, 2008 at 10:49 PM, szczepiq
> <szcz...@gmail.com <mailto:szcz...@gmail.com>

> >>>>> <mailto:szcz...@gmail.com <mailto:szcz...@gmail.com>>>

> wrote:
> >>>>> >> > I played with this a bit (not yet merged to trunk,
> though). I
> >>>>> think
> >>>>> >> > it's way cooler to get "Unstubbed method was
> invoked here"
> >>>>> instead of
> >>>>> >> > NPE.
> >>>>> >> >
> >>>>> >> > 1. I'm slowly thinking about making SMART_NULLS a
> default
> >>>>> behavior of
> >>>>> >> > any mock.
> >>>>> >> > 2. Another thing to discuss is how to approach
> collections -
> >>>>> return
> >>>>> >> > empty collections or SMART_NULLS (I'm voting for empty
> >>>>> collections).
> >>>>> >> > 3. Does it make sense to keep variants like
> SMART_NULLS / MOCKS /
> >>>>> >> > NULLS if the default behavior will be SMART_NULLS?
> >>>>> >> >
> >>>>> >> > Cheers,
> >>>>> >> > Szczepan Faber
> >>>>> >> >
> >>>>> >> > On Thu, Oct 16, 2008 at 10:33 PM, Igor Czechowski
> >>>>> >> > <iczec...@gmail.com

> <mailto:iczec...@gmail.com> <mailto:iczec...@gmail.com

> <mailto:iczec...@gmail.com>>> wrote:
> >>>>> >> >>
> >>>>> >> >> I've uploaded the svn patch into Rietveld. The link is
> >>>>> >> >> http://codereview.appspot.com/7301
> >>>>> >> >>
> >>>>> >> >> Cheers,
> >>>>> >> >> Igor
> >>>>> >> >>
> >>>>> >> >> On Thu, Oct 16, 2008 at 10:54 AM, Dan North
> >>>>> <tast...@gmail.com <mailto:tast...@gmail.com>

> <mailto:tast...@gmail.com <mailto:tast...@gmail.com>>> wrote:
> >>>>> >> >>> It was a "late substitution". We decided during
> the main
> >>>>> conference
> >>>>> >> >>> that we
> >>>>> >> >>> should use JUnit 4 and Mockito because we think
> they are the
> >>>>> future of
> >>>>> >> >>> TDD
> >>>>> >> >>> and mocking in Java ;)
> >>>>> >> >>>
> >>>>> >> >>>
> >>>>> >> >>> 2008/10/15 szczepiq <szcz...@gmail.com
> <mailto:szcz...@gmail.com>

> >>>>> <mailto:szcz...@gmail.com <mailto:szcz...@gmail.com>>>

> >>>>> >> >>>>
> >>>>> >> >>>> Cool, thanks for the info. I looked it up on the
> jaoo agenda
> >>>>> >> >>>>
> >>>>>
> (http://jaoo.dk/aarhus-2008/presentation/Test+Driven+Development).
> >>>>> >> >>>> It's written there that you've used jmock when
> you actually
> >>>>> have used
> >>>>> >> >>>> mockito. Cheaters :)
> >>>>> >> >>>>
> >>>>> >> >>>> Szczepan
> >>>>> >> >>>>
> >>>>> >> >>>> On Wed, Oct 15, 2008 at 9:40 PM, Dan North
> >>>>> <tast...@gmail.com <mailto:tast...@gmail.com>

> <mailto:tast...@gmail.com <mailto:tast...@gmail.com>>>

> >>>>> <mailto:szcz...@gmail.com <mailto:szcz...@gmail.com>>>

> >>>>> >> >>>> >>
> >>>>> >> >>>> >> Cool! I'll definitely give it a go. I think
> I'm gonna
> >>>>> just get it
> >>>>> >> >>>> >> from
> >>>>> >> >>>> >> bitbucket first. Just after I finish off the
> >>>>> presentation for
> >>>>> >> >>>> >> tomorrow
> >>>>> >> >>>> >> JDD'08 :)
> >>>>> >> >>>> >>
> >>>>> >> >>>> >> Szczepan Faber
> >>>>> >> >>>> >>
> >>>>> >> >>>> >> On Wed, Oct 15, 2008 at 8:30 PM, Dan North
> >>>>> <tast...@gmail.com <mailto:tast...@gmail.com>

> <mailto:tast...@gmail.com <mailto:tast...@gmail.com>>>

> >>>>> <mailto:tast...@gmail.com <mailto:tast...@gmail.com>>>

> >>>>> >> >>>> >> >>
> >>>>> >> >>>> >> >> It depends on the network connection. I
> left it running
> >>>>> >> >>>> >> >> overnight
> >>>>> >> >>>> >> >> (!)
> >>>>> >> >>>> >> >> for
> >>>>> >> >>>> >> >> the full thing. If you can get onto the
> actual server box
> >>>>> >> >>>> >> >> apparently
> >>>>> >> >>>> >> >> it's
> >>>>> >> >>>> >> >> super-fast from a file:// repository. Over
> http it's
> >>>>> not the
> >>>>> >> >>>> >> >> fastest.
> >>>>> >> >>>> >> >>
> >>>>> >> >>>> >> >> Cheers,
> >>>>> >> >>>> >> >> Dan
> >>>>> >> >>>> >> >>
> >>>>> >> >>>> >> >>
> >>>>> >> >>>> >> >> 2008/9/29 szczepiq <szcz...@gmail.com
> <mailto:szcz...@gmail.com>

> >>>>> <mailto:szcz...@gmail.com <mailto:szcz...@gmail.com>>>

> >>>>> >> >>>> >> >>>
> >>>>> >> >>>> >> >>> Ok, cool.
> >>>>> >> >>>> >> >>>
> >>>>> >> >>>> >> >>> How long did the convert take? I'm
> wondering how
> >>>>> fast is hg
> >>>>> >> >>>> >> >>> convert.
> >>>>> >> >>>> >> >>>
> >>>>> >> >>>> >> >>> cheers,
> >>>>> >> >>>> >> >>> Szczepan
> >>>>> >> >>>> >> >>>
> >>>>> >> >>>> >> >>> On Mon, Sep 29, 2008 at 9:59 AM, Dan North
> >>>>> >> >>>> >> >>> <tast...@gmail.com

> <mailto:tast...@gmail.com> <mailto:tast...@gmail.com

> >>>>> <mailto:robert...@gmail.com

> <mailto:robert...@gmail.com>>>
> >>>>> >> >>>> >> >>> >>
> >>>>> >> >>>> >> >>> >> On 25 Sep, 15:35, szczepiq
> <szcze...@gmail.com <mailto:szcze...@gmail.com>

> >>>>> <mailto:szcze...@gmail.com <mailto:szcze...@gmail.com>>>

[Per Lundholm]

Might have been the wrong sender - my bad.

On Sun, Nov 2, 2008 at 8:23 AM, Per Lundholm <per.lu...@crisp.se> wrote:

Well, as of mockito 1.5, if a method returns a primitive, it is a value. 

If it returns an object, it returns null, which is not a value.

Rather than null, I would like it to return a "null object", if you are familiar with that pattern.

Such an object makes it possible to continue executing a lot longer. 

In this context, the implementation of a "null object" is a mock of that object's class.

An alternative approach would be to throw an exception, say "NotStubbedException". 

But you could use "verify" if you wish to control that no methods are called that you didn't expect.

Oh, and that is one of the charming things about Mockito, you don't have to set up expectation for everything your unit under test is doing. 

I now like to know if you still potentially disagree with me. :)

/Per

[Gili Tzabari]

Replies below.

Per Lundholm wrote:
> Might have been the wrong sender - my bad.
>
> On Sun, Nov 2, 2008 at 8:23 AM, Per Lundholm <per.lu...@crisp.se
> <mailto:per.lu...@crisp.se>> wrote:
>
> Well, as of mockito 1.5, if a method returns a primitive, it is a
> value.
>
> If it returns an object, it returns null, which is not a value.
>
> Rather than null, I would like it to return a "null object", if you
> are familiar with that pattern.
>
> Such an object makes it possible to continue executing a lot longer.
>
> In this context, the implementation of a "null object" is a mock of
> that object's class.
>
> An alternative approach would be to throw an exception, say
> "NotStubbedException".
>
> But you could use "verify" if you wish to control that no methods
> are called that you didn't expect.

Correct me if I'm wrong, but I don't believe there is a way to tell
Mockito to verify() that no unstubbed method was invoked. That is, I
could verify that *specific* methods weren't invoked, but there is no
way to verify that none of the unstubbed methods were invoked.

> Oh, and that is one of the charming things about Mockito, you don't
> have to set up expectation for everything your unit under test is
> doing.
>
> I now like to know if you still potentially disagree with me. :)

I'd have to try this out for myself before I making up my mind. In
theory this could work very nicely, but I want to try it out to fully
understand the implications.

For example, what happens if I don't stub EntityManager and my code
invokes:

Query query = EntityManager.createQuery("queryString");
List result = query.getResultList();
return result;

then later on some code invokes:

if (result.contains(referenceObject))
...

This is pretty critical logic and it's not clear what Mockito should do
in this case (I would expect it to throw an exception because who knows
whether returning true or false is expected here). In this particular
case, I'd want to stub the Query to return a database row and if I
forget to do so that's a problem. At least that's what makes sense to me
now...

Gili

[Per Lundholm]

You are correct in that is no way to verify that only stubbed methods
where called.

You would have to explicitly mention them one by one. From the examples:

verify(mockOne, never()).add("two");

Or you could say that a mock is never involved in any interactions

//verify that other mocks were not interacted
verifyZeroInteractions(mockTwo, mockThree);

Now you example:

> For example, what happens if I don't stub EntityManager and my code
> invokes:
>
> Query query = EntityManager.createQuery("queryString");
> List result = query.getResultList();
> return result;
>
> then later on some code invokes:
>
> if (result.contains(referenceObject))
> ...
>
> This is pretty critical logic and it's not clear what Mockito should do
> in this case (I would expect it to throw an exception because who knows
> whether returning true or false is expected here). In this particular
> case, I'd want to stub the Query to return a database row and if I
> forget to do so that's a problem. At least that's what makes sense to me
> now...

Well, to me, it seems that EntityManager is a mock and you have not
stubbed createQuery, right?

Then createQuery will return a mock of Query and its getResultList
will return a mock of a List.

The method "contains" returns a boolean for which the default value is "false".

If you would want something else to happen, you should stub so. ;-)

I may have made some stupid mistakes above, so someone (szczepiq,
North) should better read this
and slap me.

Cheers!
Per

[Gili Tzabari]

I think this technique is fine if you are able to add
verify(myMock).onlyInvokedStubbedMethods() -- pick a nicer name but you
get the point. I'm not saying you should add this method to the API
immediately but rather that you should be sure that it's implementable.
If it's possible then I'm fine with this approach.

Gili