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%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]. For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.
