Support for chained call mocking

[GoogleCodeExporter]

For example:

def mock = mock()
mock.methodA().chains().methodB().returns(1)
mock.methodA().chains(ClassA).methodB().returns(2) // explicitly declare
the class of the result of methodA() is ClassA
play {
  assertEquals 1, mock.methodA().methodB()
  assertEquals 2, mock.methodA().methodB()
}

Original issue reported on code.google.com by JohnnyJianHY on 21 Mar 2009 at 2:03

[GoogleCodeExporter]

Original comment by julien.g...@gmail.com on 29 Mar 2009 at 12:00

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 21 Apr 2009 at 8:21

• Changed state: Started

[GoogleCodeExporter]

Consider:

mock.a().chains().b().chains().c().returns(0)
play {
  mock.a().x()
}

What should the error message look like?

1)
Unexpected method call 'a().x()'
  'a().b().c()': expected 1, actual 0

2)
Unexpected method call 'x()'
  'a().b().c()': expected 1, actual 0

3)
Unexpected method call 'a().x()'
  'a()': expected 1, actual 1
  'a().b()': expected 1, actual 0
  'a().b().c()': expected 1, actual 0

4)
Unexpected method call 'x()'
  'a()': expected 1, actual 1
  'a().b()': expected 1, actual 0
  'a().b().c()': expected 1, actual 0

I prefer 1), what your opinion?

Original comment by JohnnyJianHY on 16 May 2009 at 5:39

[GoogleCodeExporter]

I agree with you, 1 look better. 

What if we provide a shortcut to the chain method with _ ?

mock.a()._.b()._.c().returns(0)

Original comment by julien.g...@gmail.com on 16 May 2009 at 10:02

[GoogleCodeExporter]

Again, I don't quite like the underscore. It doesn't look like a normal 
property or
method. Perhaps something else?

PS: don't you think "._." looks like a face with two eyes and a mouth :)

Original comment by JohnnyJianHY on 16 May 2009 at 2:01

[GoogleCodeExporter]

Perhaps we just allow

mock.a().b().c().returns(0)

?

Original comment by JohnnyJianHY on 16 May 2009 at 2:09

[GoogleCodeExporter]

You are right this would be ideal: mock.a().b().c().returns(0).

I can't remember why we discarded it in the first place.

Original comment by julien.g...@gmail.com on 18 May 2009 at 6:01

[GoogleCodeExporter]

Because if someone mistyped 'mock.a().times(1)' with 'mock.a().time(1)', we 
cannot tell.

Original comment by JohnnyJianHY on 18 May 2009 at 7:45

[GoogleCodeExporter]

I remember now... that's a bit annoying.

What about mock.chain().a().b().c().returns(0) that's the best compromise I can 
think of.

Original comment by julien.g...@gmail.com on 18 May 2009 at 5:24

[GoogleCodeExporter]

I don't think so. That means we cannot mock a method named 'chain()'.

Original comment by JohnnyJianHY on 19 May 2009 at 1:07

[GoogleCodeExporter]

Of course we can do mock.chain(). I think the issue regarding the mistyping is 
quite big and we should probably 
do what we had originally in mind.

Original comment by julien.g...@gmail.com on 20 May 2009 at 7:33

[GoogleCodeExporter]

How to mock 'chain()' then?

Original comment by JohnnyJianHY on 20 May 2009 at 7:39

[GoogleCodeExporter]

I was thinking about our original idea: 
mock.methodA().chains().methodB().returns(1)

Original comment by julien.g...@gmail.com on 20 May 2009 at 12:23

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 1 May 2011 at 9:07

• Changed state: Fixed

[GoogleCodeExporter]

It is surprising that this works:

mock.fun(1) chains .gun(2) returns 3
// it equals to:
// mock.fun(1).chains.gun(2).returns(3)

Is it more readable?

Original comment by JohnnyJianHY on 20 Dec 2011 at 12:55