Stubbing behavior

[Tim Barcz]

Am curious what you all see as the correct behavior.  Am thinking about making an enhancement where the last value set on a stub is what is used. The usage scenario is that I have some common set up code and in some tests want to override with a new stubbed value, however when using expressions the new updated value "doesn't take" (it uses the original).  When using setable properties (ie. PropertyBehavior) the last set value is the one that is returned (which allows me to override as I wish).

Here's an example...which is proper (I'm proposing that the ShowSetable example should be allowed (ie. "last in wins")).  What am I overlooking?

public interface IFoo
{
    bool ReadProperty { get; }
    bool SetableProperty { get; set; }
}

[Test]
public void ShowReadable()
{
        var order = MockRepository.GenerateStub<IFoo>();

        order.Stub(x => x.ReadProperty).Return(false);
        order.Stub(x => x.ReadProperty).Return(true);

        Console.WriteLine(order.ReadProperty );
        Console.WriteLine(order.ReadProperty);
}

Returns: False, False ("first in wins")

[Test]
public void ShowSetable()
{
    var order = MockRepository.GenerateStub<IFoo>();

    order.SetableProperty = false;
    order.SetableProperty = true;

    Console.WriteLine(order.SetableProperty);
    Console.WriteLine(order.SetableProperty);
}

Returns: True, True ("last in wins")

Tim

--
Tim Barcz
Microsoft C# MVP
Microsoft ASPInsider
http://timbarcz.devlicio.us
http://www.twitter.com/timbarcz

[bill richards]

The second example seems more intuitive to me ... if I've set a
property's value that's what I expect to get when I use the getter.

[Tim Barcz]

Is this what you would expect to see in the first example (where it
does not work...yet)?

Tim

On 10/30/09, bill richards <bill.r...@greyskin.co.uk> wrote:
>
> The second example seems more intuitive to me ... if I've set a
> property's value that's what I expect to get when I use the getter.
> >
>

--
Sent from my mobile device

[bill richards]

I would expect the same net behaviour in both cases, that being that I
would expect any subsequent call to get_Property after stubbing
set_Property to give me that LAST item that set_Property was stubbed
with.

On Oct 30, 8:04 pm, Tim Barcz <timba...@gmail.com> wrote:
> Is this what you would expect to see in the first example (where it
> does not work...yet)?
>
> Tim
>

[Tim Barcz]

Just to follow up on this I've looked into this and the problem is that I could see this adding confusion.  In the example below I made it work so that the value of "true" was returned (last in wins).  It seems like this could break some fundamental assumptions about RhinoMocks since what I'm doing is updating previous set expectations.

Thoughts?

public interface IFoo
{
    bool ReadProperty { get; }
    bool SetableProperty { get; set; }
}

[Test]
public void ShowReadable()
{
        var order = MockRepository.GenerateStub<IFoo>();

        order.Stub(x => x.ReadProperty).Return(false);
        order.Stub(x => x.ReadProperty).Return(true);

        Console.WriteLine(order.ReadProperty );
}

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.
To post to this group, send email to rhino...@googlegroups.com
To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en
-~----------~----~----~----~------~----~------~--~---

--

Tim Barcz
Microsoft C# MVP

[bill richards]

My money says that that is the behaviour I would expect

On Nov 21, 5:11 pm, Tim Barcz <timba...@gmail.com> wrote:
> Just to follow up on this I've looked into this and the problem is that I
> could see this adding confusion.  In the example below I made it work so
> that the value of "true" was returned (last in wins).  It seems like this
> could break some fundamental assumptions about RhinoMocks since what I'm
> doing is updating previous set expectations.
>
> Thoughts?
>
> public interface IFoo
> {
>     bool ReadProperty { get; }
>     bool SetableProperty { get; set; }
>
> }
>
> [Test]
> public void ShowReadable()
> {
>         var order = MockRepository.GenerateStub<IFoo>();
>
>         order.Stub(x => x.ReadProperty).Return(false);
>         order.Stub(x => x.ReadProperty).Return(true);
>
>         Console.WriteLine(order.ReadProperty );
>
> }
>

> On Fri, Oct 30, 2009 at 2:37 PM, bill richards <bill.richa...@greyskin.co.uk

>
>
>
>
>
> > wrote:
>
> > I would expect the same net behaviour in both cases, that being that I
> > would expect any subsequent call to get_Property after stubbing
> > set_Property to give me that LAST item that set_Property was stubbed
> > with.
>
> > On Oct 30, 8:04 pm, Tim Barcz <timba...@gmail.com> wrote:
> > > Is this what you would expect to see in the first example (where it
> > > does not work...yet)?
>
> > > Tim
>
> > > On 10/30/09, bill richards <bill.richa...@greyskin.co.uk> wrote:
>
> > > > The second example seems more intuitive to me ... if I've set a
> > > > property's value that's what I expect to get when I use the getter.
>
> > > --
> > > Sent from my mobile device
>
> > > 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 rhino...@googlegroups.com
> > To unsubscribe from this group, send email to

> > rhinomocks+...@googlegroups.com<rhinomocks%2Bunsubscribe@googlegrou­ps.com>

> > 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- Hide quoted text -
>
> - Show quoted text -

[Iain Waddell]

This is the behaviour I was looking for when I started using Rhino Mocks. I had to mess around because it didn't do this. I welcome the change.

Iain

2009/11/21 bill richards <bill.r...@greyskin.co.uk>

--

You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.

To post to this group, send email to rhino...@googlegroups.com.
To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=.

[Alex McMahon]

I agree that "last in wins" makes more sense than "first in" looking at the example I think you might think that it will create a queue of stubbed responses.

2009/11/21 Iain Waddell <iain.w...@gmail.com>

[bill richards]

> 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?

[Tim Barcz]

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.

--

You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group.
To post to this group, send email to rhino...@googlegroups.com.
To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=.

--

Tim Barcz
Microsoft C# MVP

[Mark Whitfeld]

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 Team
http://www.habanerolabs.com

On Nov 22, 4:09 pm, Tim Barcz <timba...@gmail.com> 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 <bill.richa...@greyskin.co.uk

> > rhinomocks+...@googlegroups.com<rhinomocks%2Bunsu...@googlegroups.com>
> > .

[Mark Whitfeld]

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 <mark.w...@gmail.com> 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

[Tim Barcz]

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

To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.

--
Tim Barcz
Microsoft C# MVP

[Mark Whitfeld]

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 <timba...@gmail.com> 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 <mark.whitf...@gmail.com>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
>

> > <rhinomocks%2Bunsu...@googlegroups.com<rhinomocks%252Buns...@googlegroups.com>

>
> > > > > .
> > > > > 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 rhino...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rhinomocks+...@googlegroups.com<rhinomocks%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at

[David Tchepak]

You may want Return(T firstValue, params T[] otherValues), otherwise
you could do .Stub(x => x.Something()).Return()
Which doesn't make much sense. :)

> To unsubscribe from this group, send email to rhinomocks+...@googlegroups.com.

[Mark Whitfeld]

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 <tche...@gmail.com> 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. :)
>

[Kenneth Xu]

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