ssacher-tgm / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

Return empty value for Iterables #175

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
Here is the corresponding patch. Cheers.

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

Attachments:

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago

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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Not bad idea. ;)

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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
Fixed on github (2.0.x)

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