Feature request: vargars version of doReturn()

[GoogleCodeExporter]

I found it that in some cases it would be useful to have the doReturn(...) 
method to accept not only a single object but also an array of these (in a 
varargs form).
IMVHO it's also good for the when(...).thenReturn(...) and 
doReturn(...).when() idioms to be symmetrical.

Currently using 1.8.4 (if it's already solved in trunk sorry for bothering)

Original issue reported on code.google.com by maciej.b...@gmail.com on 7 Apr 2010 at 9:32

[GoogleCodeExporter]

I am playing around with this and will provide a patch for this in near future.

Original comment by prozen@gmail.com on 10 Apr 2010 at 8:26

[GoogleCodeExporter]

cool, we're waiting - don't forget the tests ;)

Original comment by szcze...@gmail.com on 12 Apr 2010 at 4:20

[GoogleCodeExporter]

And here is the patch. Tests were easy to remember, but I almost forgot the 
javadoc:P

Original comment by prozen@gmail.com on 12 Apr 2010 at 5:03

Attachments:

• doReturn.txt

[GoogleCodeExporter]

Hej Maciej,

I'd like to put it in the trunk but can you possibly update your patch, please.

1. there is this annoying compiler warning if I do: doReturn(null).when.... 
Have a
look how it is done for when() style of stubbing.
2. can you push down the logic from Mockito.doReturn(varargs) somewhere deeper
(perhaps new ReturnsConsecutively() - not sure)

Cheers,
PS.
sorry for doing it so late... ;]

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

[GoogleCodeExporter]

Hi Szczepan,

Actually it's not me, who created the patch. @prozen, do you want to update it? 
I can 
have a go at it as well.

Cheers, m.

Original comment by maciej.b...@gmail.com on 24 May 2010 at 2:29

[GoogleCodeExporter]

sure, go ahead

Original comment by szcze...@gmail.com on 24 May 2010 at 3:34

[GoogleCodeExporter]

I'll update it tonight...

Original comment by prozen@gmail.com on 24 May 2010 at 4:38

[GoogleCodeExporter]

And here is the new version.
Issue 1 is solved in the same way as for when() style, and with the same 
limitation: 
doReturn(null, null) still has warning, but that should happen less often(and 
can't 
be fixed, I think).

Issue 2 is fixed, but I had to change data structure in 
StubbedInvocationMatcher 
since I needed to be able to add elements from both sides which is something I 
am not 
too happy with, but I don't really see a better way if you want to push down 
the 
implementation.

Original comment by prozen@gmail.com on 24 May 2010 at 9:59

Attachments:

• doReturn.txt

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 9 Mar 2012 at 11:53

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Dont remember whats the state of things here but whatever we do we should make 
sure there are no warnings for majority of regular use cases ;)

Original comment by szcze...@gmail.com on 10 Mar 2012 at 1:35

[GoogleCodeExporter]

Hi Szczepan

I'd really like to see this because we are solely using doReturn(...) stubbing 
in favour of having the same syntax for all cases. The only case that does not 
work so far is the one of this issue with multiple return values.

A patch exists for around two years now. Will it be applied soon? The only 
drawback mentioned is a warning that is also showing for the same case in the 
already implemented when(...).thenReturn(null, null) stubbing. And this warning 
cannot be removed because it has nothing to do with the Mockito API but is a 
general Java warning for logical disambiguation of method calls. So this would 
make no difference at all and thus shuld not be a reason to not apply the patch.

Cheers, tilmann

Original comment by tilm...@googlemail.com on 22 Aug 2012 at 9:38