Patch to add a revolving return - returnIterator

[y2k4...@gmail.com]

Mock<ICacheClock> mockClock = new Mock<ICacheClock>();
mockClock.Expect(c => c.GetCurrentTime())
.Returns("10:00pm", "10:30pm", "10:35");

This can be done currently but requires a lot of code in the unit
testing. This does not provide for a clean test. Having it in the test
also requires some logic to prevent an error if a call to
GetCurrentTime is called more than what is in the Array. Again more
code could be placed in the unit test to reset the counter, but again
does not provide a clean test.

int recordCounter = 0;
object[] values = new object[3] {"10:00pm", "10:30pm", "10:35");
Mock<ICacheClock> mockClock = new Mock<ICacheClock>();
mockClock.Expect(c => c.GetCurrentTime())
.Returns(() => object[recordCounter++]);

This just show what to do if you wanted to return three values, but if
GetCurrentTime is called a fourth time then you will get an error.
(index out of range / recordCounter = 3)

Again I don't know if the design would be to continually return the
next value and start over from the start or to throw an error when the
last value is reached. I just know that the demo code I'm writing that
requires this functionality works.

I got the source via SVN.
Made some code changes.
Built a patch file. (PatchToAddReturnIterator .patch)
Now what?



- Guy

[Daniel Cazzulino]

We're evaluating a different approach to solving this.

Brian is working on the proposal to support sequences, where you can setup multiple expectations for the same method/args to be matched in a sequence. This would allow to also set sequencing across methods, which is necessary to support very tight interaction testing (I wouldn't advice using this too much).

stay tunned!

[y2k4...@gmail.com]

When you say

"I wouldn't advice using this too much"

Do you mean in general that sequence returns are bad?
I understand that they are not ideal but they do play a part. That is
why I was using a clock as an example. Becuase in a real world
situation that method would not return the same value everytime it is
called. If you have a timed base problem to solve then one would want
control over simulating the change of time. Or a random number
generator but you want to control the output nubmers to be in a
particular sequence.

If one was not to use this concept then what would they use? Or how
would they mock a sequence of returned values?

I'm also concerned with the implmentation in my unit test and not
wanting too much complexity or bloat. Is what Brian proposing give us
a simple declaration like .Return(x, y, z)? That proposal sounds broad
and trying to solve two problems. One of which is sequencing and
making sure methods are called in a proper order. Making sure method A
is called before method B. And combining that with a .Return that
returns a sequence of numbers for the a single expectation with a
single method/args pattern.

> > - Guy- Hide quoted text -
>
> - Show quoted text -

[Daniel Cazzulino]

> "I wouldn't advice using this too much"

> Do you mean in general that sequence returns are bad?

I meant that setting up expectations with sequencing across invocations and probably even mocks is risky as you're tying your mocks too much to the internals of the various interactions. But that's just my opinion ;)

I think Brian's approach may be similar to this:

var sequence = new MockSequence();

sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(5);
sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(10);
sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(15);

so you can see how the same expectation is set three times with different return values each time.

this is work in progress, though.

[Daniel Cazzulino]

nope

there hasn't been overwhelming demand for it either :)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

On Fri, Mar 13, 2009 at 5:57 PM, Leo <leod...@gmail.com> wrote:

Did this ever get implemented?

On Apr 29 2008, 12:43 pm, "Daniel Cazzulino" <dan...@cazzulino.com>

wrote:

> > "I wouldn't advice using this too much"
> > Do you mean in general that sequence returns are bad?
>
> I meant that setting up expectations with sequencing across invocations and
> probably even mocks is risky as you're tying your mocks too much to the
> internals of the various interactions. But that's just my opinion ;)
>
> I think Brian's approach may be similar to this:
>
> var sequence = new MockSequence();
>
> sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(5);
> sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(10);
> sequence.Expect<IFoo>(foo => foo.Do(1)).Returns(15);
>
> so you can see how the same expectation is set three times with different
> return values each time.
>
> this is work in progress, though.
>