Sorry, My example was pretty rushed and didn't explain what happened in production. You are right, the example didn't seem to test anything. But it did prove that x.Stub could be called many times and x.Expect could only be called once.
If you change my example and make: var bin = new Bin(); And bin is a property of house: var house = new House(); house.Stub(x => x.Bin).Return(bin); By using x.Stub instead of x.Expect, I can push house through a business object that I am trying to test. That business object may make modifications to bin and therefore call bin - as a property of house - many times. Allowing me to test that bin comes out of the business object with the data I expect. I normally push a mocked/fake/stubbed data access layer into the business object, so that I am testing the workflow through a business layer. I don't believe this to be a 'unit' test, but it is still a test I can run, using unit test methods. On Dec 22, 4:55 pm, bill richards <[email protected]> wrote: > Kam, > > I could not fail to notice that you are not Asserting that your > expectations have been met! > > i.e. : > > [Test] > public void TestStub() > { > // Arrange > var bin = MockRepository.GenerateStub<IBin>(); > // I would Stub this call instead of using Expect > bin.Stub(x => x.IsFull).Return(false); > > var dustBin = MockRepository.GenerateStub<IDustbin>(); > // I would Stub this call instead of using Expect > dustBin.Stub(x => x.IsFull).Return(false); > > var myHouse = MockRepository.GenerateStub<IHouse>(); > myHouse.Expect(x => x.Bin).Return(bin); > myHouse.Expect(x => x.Dustbin).Return(dustBin); > > // Act > var cleaner = new Cleaner(); > cleaner.EmptyTheBins(myHouse); > > // Assert > // This line is missing > myHouse.VerifyAllExpectations(); > } > > But then again, I'm not entirely sure what is actually being > tested .... > > My rule of thumb is as follows: If the object is not being tested, use > a Stub. If the object is being tested set an Expectation > > So, in the example above, I have assumed that it is your IHouse > implementation that is being tested, and not the IBin or IDustbin > implementations. > > Stub = when a particular member is invoked, I want x to happen > (every time). > Expect = when a particular member is invoked, I am expecting x to > occur. > > Expectations can occur multiple times simply by using .Times(n), i.e. > > myHouse.Expect(x => x.Bin).Return(bin).Times(2); > > however, your test will fail with the call to > myHouse.VerifyAllExpectations(), since the call is only ever made once > (unless you are stepping through in debug mode and inspecting your > objects). > > On Dec 22, 4:31 pm, Kam <[email protected]> wrote:> I figured out the problem > I was having. It appears that when I use > > x.Expect - it is a 'once only' call. Once I've called it, I can't > > call it again. This is why I couldn't see a problem when I ran the > > tests. The tests call the operations once and work! > > > However, if I am trying to debug it and need to hover over properties > > to find out what they hold, the thing goes pear shaped. Because when > > I hover over the property, I have made that 'once only' call. > > > If I use, x.Stub though, it works as many times as I like! > > > Here is an example of what I was doing. > > > [TestFixture] > > public class TestStubAgainstExpect > > { > > [Test] > > public void TestStub() > > { > > var bin = MockRepository.GenerateStub<IBin>(); > > bin.Expect(x => x.IsFull).Return(false); > > > var dustBin = MockRepository.GenerateStub<IDustbin>(); > > dustBin.Expect(x => x.IsFull).Return(false); > > > var myHouse = MockRepository.GenerateStub<IHouse>(); > > > //can not debug/hover over > > myHouse.Expect(x => x.Bin).Return(bin); > > myHouse.Expect(x => x.Dustbin).Return(dustBin); > > > //can debug/hover over > > // myHouse.Stub(x => x.Bin).Return(bin); > > // myHouse.Stub(x => x.Dustbin).Return(dustBin); > > > var cleaner = new Cleaner(); > > cleaner.EmptyTheBins(myHouse); > > } > > } > > > public class Cleaner > > { > > internal Cleaner() > > { > > } > > > public void EmptyTheBins(IHouse house) > > { > > if (house.Bin.IsFull) > > { > > //empty the bins > > } > > } > > } > > > public interface IBin > > { > > bool IsFull { get;} > > } > > > public interface IHouse > > { > > IBin Bin { get; } > > IDustbin Dustbin { get; } > > } > > > public interface IDustbin > > { > > bool IsFull { get; } > > } > > > On Dec 22, 11:35 am, Tim Barcz <[email protected]> wrote: > > > > I'd prefer something that compiles > > > > Sent from my iPhone > > > > On Dec 21, 2009, at 11:36 PM, John Bierman <[email protected]> wrote: > > > > > 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 > > > > >>>>> %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 > > > > > 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 > > > > 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 > > > > athttp://groups.google.com/group/rhinomocks?hl=en > > > > .- Hide quoted text - > > > - Show quoted text - -- 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.
