Closed GoogleCodeExporter closed 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
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
Here is the corresponding patch. Cheers.
Original comment by eric...@gmail.com
on 26 Mar 2010 at 4:15
Attachments:
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
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
Original comment by szcze...@gmail.com
on 30 May 2010 at 6:19
[deleted comment]
Not bad idea. ;)
Original comment by szcze...@gmail.com
on 25 Nov 2011 at 7:43
[deleted comment]
[deleted comment]
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
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
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
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
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
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
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
Fixed on github (2.0.x)
Original comment by brice.du...@gmail.com
on 3 Jun 2015 at 4:58
Original issue reported on code.google.com by
eric...@gmail.com
on 5 Mar 2010 at 9:50