Return empty value for Iterables

[GoogleCodeExporter]

Mockito should return an empty iterable when a method returns an Iterable.

Currently, if a method in a mocked object is supposed to return a 
Collection, for example:

interface Foo {
  Collection bar();
}

then Mockito actually returns an empty collection. Excellent default 
behavior.

Now, if another method returns Iterable:
interface Foo {
  Iterable iterableBar();
}

then Mockito returns null.

It would be nicer if it returns an empty iterable instead.

Thanks

Original issue reported on code.google.com by eric...@gmail.com on 5 Mar 2010 at 9:50

[GoogleCodeExporter]

Yeah, it makes perfect sense.

Can you provide a patch and test? :)

Original comment by szcze...@gmail.com on 7 Mar 2010 at 11:05

[GoogleCodeExporter]

Yes, I'm certainly planning to work on it. Feel free (anyone) to contribute 
before I 
do, though.

Original comment by eric...@gmail.com on 8 Mar 2010 at 9:11

[GoogleCodeExporter]

Here is the corresponding patch. Cheers.

Original comment by eric...@gmail.com on 26 Mar 2010 at 4:15

Attachments:

• iterable.stubbing.diff

[GoogleCodeExporter]

Thanks for the patch. This will definitely go to Mockito! However, I think I'm 
going
to wait a for 2.0 because I don't want to break backwards compatibility.

Cheers!
PS.
sorry for late notice but again google didn't notify me about your change to 
this
ticket :(

Original comment by szcze...@gmail.com on 24 May 2010 at 5:25

[GoogleCodeExporter]

I don't mind waiting for a later version of Mockito. I do think, though, that 
this 
would be minor enough so that it would be acceptable.
When I say "minor", it is in the sense that we, for example, ended up 
instrumented 
each case where we use Iterable (which are not that many).

But it's your call, of course.

Original comment by eric...@gmail.com on 24 May 2010 at 8:54

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 30 May 2010 at 6:19

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Not bad idea. ;)

Original comment by szcze...@gmail.com on 25 Nov 2011 at 7:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'd like to make this answer configurable in the mean time. (Using the 
MockitoConfiguration way).

Original comment by brice.du...@gmail.com on 24 Feb 2012 at 4:21

[GoogleCodeExporter]

What do you mean 'this' answer? We already have the default return values 
configurable via MockitoConfiguration.

Original comment by szcze...@gmail.com on 24 Feb 2012 at 9:56

[GoogleCodeExporter]

I'd like to toggle the default behavior of returning an empty iterable or null.

Original comment by brice.du...@gmail.com on 24 Feb 2012 at 10:00

[GoogleCodeExporter]

I wouldn't go that far. It does not seem sensible to have a extension point for 
a single return type (i.e. Iterable). Following that strategy we should add 
extension points for other types, too. Unless Iterable is more important than 
others :)

Also, if the use case is to change the default return value for Iterable then 
this is already possible - one can just configure global default answer that 
returns X for iterables and delegates to EmptyReturnValues (the regular mockito 
behavior) for any other types.

Thoughts?

Original comment by szcze...@gmail.com on 24 Feb 2012 at 10:13

[GoogleCodeExporter]

Yeah you are right, it does make sense to use another default answer.

Actually the idea behind is to create a transition beween the old behavior 
(incorrect) and the new one (returning an empty iterable). I think we should 
take the opportunity to change this on medium revison ie from 'a.8.c' to 
'a.9.0'.

Original comment by brice.du...@gmail.com on 24 Feb 2012 at 10:21

[GoogleCodeExporter]

Oh, I see. Maybe there is a way to introduce the change 'gently'. For example 
we could detect when a test's behavior depends on the return value from a 
Iterable-returning method of a mockito mock. We could log some kind of 
deprecation warning. Alternatively we could fail fast with a meaningful 
exception saying that we have changed the default value and what are steps to 
make sure the test still behaves well.

Original comment by szcze...@gmail.com on 24 Feb 2012 at 10:33

[GoogleCodeExporter]

Yeah I'd rather use the second option. It's a bold move, but much more safe to 
fail fast than being to smart for a such defect.

Original comment by brice.du...@gmail.com on 5 Mar 2012 at 4:24

[GoogleCodeExporter]

Fixed on github (2.0.x)

Original comment by brice.du...@gmail.com on 3 Jun 2015 at 4:58

• Changed state: Fixed