There was a very similar discussion in another Mock framework's mailing list and they end up with
.Return(first).Return(second) and so on. It's much cleaner to me that way. Just my 2 cents. Cheers, Kenneth On Tue, Dec 15, 2009 at 2:44 AM, Mark Whitfeld <[email protected]> wrote: > Ah, very true! Didn't think about that. > So then, if you had the signature "Return(T firstValue, params T[] > otherValues)" > then you would have a way of specifying multiple ordered return values > that supports the last-in-wins. > Sounds good to me :) > > Mark Whitfeld > Habanero Development Team > http://www.habanerolabs.com > > On Dec 14, 1:18 pm, David Tchepak <[email protected]> wrote: >> You may want Return(T firstValue, params T[] otherValues), otherwise >> you could do .Stub(x => x.Something()).Return() >> Which doesn't make much sense. :) >> >> On Mon, Dec 14, 2009 at 6:24 PM, Mark Whitfeld <[email protected]> >> wrote: >> > Yeah, the only change to the public interface would be from Return(T >> > value) to Return(params T[] values) >> > The great thing about this is that this change will not break old >> > code. >> > I'm sure the internal changes would be quite substantial though, but >> > worth it!!! >> > I regularly come across situations where this kind of thing is needed. >> > Especially when I have some sort of Factory pattern for instance >> > creation. >> >> > Mark Whitfeld >> > Habanero Development Team >> >http://www.habanerolabs.com >> >> > On Dec 11, 5:24 pm, Tim Barcz <[email protected]> wrote: >> >> When I initially looked at it I thought it make some sense, however the >> >> implementation is a bit interesting because now rather than using "Return" >> >> the correct type you're you have to pass in a params array of the correct >> >> type. I believe it's doable, but it also increases the surface area of >> >> the >> >> code base. >> >> >> Tim >> >> >> On Fri, Dec 11, 2009 at 6:03 AM, Mark Whitfeld >> >> <[email protected]>wrote: >> >> >> > Hi Tim >> >> >> > I was wondering what your verdict was with the correct behaviour for >> >> > ordered returns, etc. >> >> > Have you had a look at my suggestion above? >> >> > I think that it would solve all ambiguity. >> >> >> > Mark Whitfeld >> >> > Habanero Development Team >> >> >http://www.habanerolabs.com >> >> >> > On Nov 23, 9:10 am, Mark Whitfeld <[email protected]> wrote: >> >> > > I would definitely agree that last in should win, but also that it >> >> > > would be nice to have something like what Tim suggested above. >> >> > > I thought of another syntax for this possibility. How about: >> >> >> > > mock.Stub(x=>x.Foo()).Return(1,2); >> >> >> > > This would just use a parameter array to specify the desired returns >> >> > > in order and therefore you would get the 'last in' winning and the >> >> > > desired ordered returns. >> >> > > What do you think? >> >> >> > > Mark Whitfeld >> >> > > Habanero Development Teamhttp://www.habanerolabs.com >> >> >> > > On Nov 22, 4:09 pm, Tim Barcz <[email protected]> wrote: >> >> >> > > > There are cases where a call may be made twice and and each time you >> >> > want >> >> > > > something different called. >> >> >> > > > mock.Stub(x=>x.Foo()).Return(1); >> >> > > > mock.Stub(x=>x.Foo()).Return(2); >> >> >> > > > Where the first call returns 1 and the second call returns 2. >> >> >> > > > If I can pull it off I was thinking of having the framework >> >> > > > approach as >> >> > > > "last in wins" unless the expectation is explicitly set with a >> >> > > > number >> >> > of >> >> > > > times. So in the example above, if you called Foo(), 2 would be >> >> > returned >> >> > > > (last in winning). >> >> >> > > > However if you had: >> >> >> > > > mock.Stub(x=>x.Foo()).Return(1).Repeat.Once >> >> > > > mock.Stub(x=>x.Foo()).Return(2); >> >> >> > > > And then called Foo(), you would get 1 (since it was explicitly set >> >> > up). >> >> >> > > > Again I don't know if this adds to the confusion or clears it up. >> >> >> > > > On Sun, Nov 22, 2009 at 7:38 AM, bill richards < >> >> > [email protected] >> >> >> > > > > wrote: >> >> > > > > > looking at the example I think you might think that >> >> > > > > > it will create a queue of stubbed responses. >> >> >> > > > > Now that's just crazy talk! I write a fair number of C# classes, >> >> > > > > most >> >> > > > > of which contain at least one property getter and setter, for >> >> > example: >> >> >> > > > > public SomeClass { public string Text { get; set; } } >> >> >> > > > > during the course of the application running, I might instantiate >> >> > > > > SomeClass thus: >> >> >> > > > > var sc = new SomeClass { Text = "First" }; >> >> >> > > > > and then later on I might change the text thus: >> >> >> > > > > sc.Text = "Second"; >> >> >> > > > > From what you have said above Alex, we should conclude that when >> >> > > > > running the following code: >> >> >> > > > > for(var i = 0; i < 2; i++) >> >> > > > > { >> >> > > > > if(i == 0 && sc.Text == "First") >> >> > > > > Console.WriteLine("First value retrieved"); >> >> >> > > > > if(i == 1 && sc.Text == "Second") >> >> > > > > Console.WriteLine("Second value retrieved"); >> >> > > > > } >> >> >> > > > > I would expect the following output in my Command Window >> >> >> > > > > First value retrieved >> >> > > > > Second value retrieved >> >> >> > > > > but we all know that that is just nonsense .... so why would >> >> > > > > anyone >> >> > > > > expect different behaviour from a mocking framework? >> >> >> > > > > -- >> >> >> > > > > You received this message because you are subscribed to the Google >> >> > Groups >> >> > > > > "Rhino.Mocks" group. >> >> > > > > To post to this group, send email to [email protected]. >> >> > > > > To unsubscribe from this group, send email to >> >> > > > > [email protected]<rhinomocks%[email protected]> >> >> > <rhinomocks%[email protected]<rhinomocks%[email protected]> >> >> >> > > > > . >> >> > > > > For more options, visit this group at >> >> > > > >http://groups.google.com/group/rhinomocks?hl=. >> >> >> > > > -- >> >> > > > Tim Barcz >> >> > > > Microsoft C# MVP >> >> > > > Microsoft ASPInsiderhttp://timbarcz.devlicio.ushttp:// >> >> >www.twitter.com/timbarcz >> >> >> > -- >> >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "Rhino.Mocks" group. >> >> > To post to this group, send email to [email protected]. >> >> > To unsubscribe from this group, send email to >> >> > [email protected]<rhinomocks%[email protected]> >> >> > . >> >> > For more options, visit this group at >> >> >http://groups.google.com/group/rhinomocks?hl=en. >> >> >> -- >> >> Tim Barcz >> >> Microsoft C# MVP >> >> Microsoft >> >> ASPInsiderhttp://timbarcz.devlicio.ushttp://www.twitter.com/timbarcz >> >> > -- >> >> > You received this message because you are subscribed to the Google Groups >> > "Rhino.Mocks" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/rhinomocks?hl=en. >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "Rhino.Mocks" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhinomocks?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.
