Does the one that I sent you originally suffice?

On Mon, Dec 21, 2009 at 7:45 PM, Tim Barcz <[email protected]> wrote:

> I would love to... However can you provide a test for me to comment on.
>
> Tim
>
> Sent from my iPhone
>
> On Dec 21, 2009, at 5:04 PM, Kam <[email protected]> wrote:
>
> > I found a situation where I had to use x.Stub() rather than x.Expect
> > ().
> >
> > I do not know the reasons why.  Maybe someone with more knowledge of
> > the Rhino MOcks engine could explain.
> >
> > I found that when I used:
> >
> > x.Expect(x => x.SomeProperty).Return(myProperty);
> >
> > Reference to x.SomeProperty would only return myProperty within the
> > same unit.  The moment I tried to push this stub into a class
> > constructor for another class, it returned NULL to that class.
> >
> > I struggled with this, until I found x.Stub().
> >
> > I replaced the line above for:
> >
> > x.Stub(x => x.SomeProperty).Return(myProperty);
> >
> > Please be aware that x.SomeProperty is a readonly property which is
> > why I needed to declare it this way.
> >
> >
> > If anyone could shed light on why this is necessary I would be
> > interested.
> >
> > Thanks.
> >
> > On Dec 7, 7:32 pm, Fabien Arcellier <[email protected]>
> > wrote:
> >> To conclude, if I write some codes as examples, do you think that is
> >> preferable to use Expect<> in place of Stub<> ?
> >>
> >> On Dec 7, 7:29 pm, Fabien Arcellier <[email protected]>
> >> wrote:
> >>
> >>
> >>
> >>> Thanks all for your answer.
> >>
> >>> Finally I looked in the source code to verify the behavior of Stub<>
> >>> method :
> >>> I found this implementation :
> >>
> >>>                 /// <summary>
> >>>                 /// Tell the mock object to perform a certain
> >>> action when a matching
> >>>                 /// method is called.
> >>>                 /// Does not create an expectation for this method.
> >>>                 /// </summary>
> >>>                 /// <typeparam name="T"></typeparam>
> >>>                 /// <typeparam name="R"></typeparam>
> >>>                 /// <param name="mock">The mock.</param>
> >>>                 /// <param name="action">The action.</param>
> >>>                 /// <returns></returns>
> >>>                 public static IMethodOptions<R> Stub<T, R>(this T
> >>> mock, Function<T, R> action)
> >>>                         where T : class
> >>>                 {
> >>>                         return Expect(mock, action).Repeat.Times
> >>> (0, int.MaxValue);
> >>>                 }
> >>
> >>> It seems the Stub<> method does a direct call to Expect method with
> >>> repeat option.
> >>
> >>> According to method commentary, this method doesn't create an
> >>> expectation.
> >>> In fact, we create it.
> >>
> >>> I don't understand the interest of Stub<> method ... It shouldn't
> >>> declared as deprecated  ?
> >>
> >>> Regards,
> >>> Fabien Arcellier
> >>
> >>> On Dec 7, 5:45 pm, Tim Barcz <[email protected]> wrote:
> >>
> >>>> Stubs can do expectations and I've stumbled on this many times as
> >>>> have
> >>>> others...there are numerous threads about this and I believe this
> >>>> was not
> >>>> the original intended behavior but rather an evolution over
> >>>> time.  That
> >>>> said, there has been significant discussion about moving away
> >>>> from the
> >>>> notion of "mocks" and "stubs" in RhinoMocks 4.0 to something a
> >>>> bit mroe
> >>>> clear.
> >>
> >>>> On Mon, Dec 7, 2009 at 10:05 AM, bill richards
> >>>> <[email protected]
> >>
> >>>>> wrote:
> >>>>> I just modified the second test slightly, and it appears to
> >>>>> indicate
> >>>>> that the Expectation was in fact realised.
> >>
> >>>>>        [Test]
> >>>>>        public void
> >>>>> WhenUsingExpect_ShouldPassVerifyAllExpectations()
> >>>>>        {
> >>>>>            var child = MockRepository.GenerateStub<ITestChild>();
> >>>>>            child.Expect(c => c.SetParent
> >>>>> (Arg<ITestItem>.Is.Anything));
> >>
> >>>>>             var item = new TestItem(child);
> >>
> >>>>>             child.VerifyAllExpectations();
> >>>>>            child.AssertWasCalled(c => c.SetParent(item));
> >>>>>         }
> >>
> >>>>> --
> >>
> >>>>> 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
> >>>>> %2bunsubscr...@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
> >
> > --
> >
> > 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
> > .
> >
> >
>
> --
>
> 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.
>
>
>

--

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.


Reply via email to