"Mock can fail a test by just calling a method that isn't expected, that was the intention." ... so the distinction has always been made between mock and stub. Should the distinction instead be made between strict mock and mock/stub. Where the underlying differences between mock/stub go away (except for strict).
Tim On Mon, Aug 24, 2009 at 12:59 AM, Ayende Rahien <[email protected]> wrote: > Tim,Stub _doesn't_ cause the test to fail. > What you have here is an assertion on a stub, it is different. > Mock can fail a test by just calling a method that isn't expected, that was > the intention. > > And yes, they are blurry lines. > Unfortunately, backward compact means that it is going to be very hard to > change. > I think that the best alternative is to make RM 4.0 go on a diet and > declare backward compact dead there. > Adopt the suggestion of cutting the API and reducing the complexity. > > Thoughts? > > > On Mon, Aug 24, 2009 at 2:07 AM, Tim Barcz <[email protected]> wrote: > >> I was working on a post the difference between mocks and stubs with regard >> to how the framework treats them and I'm seeing some things which seem to be >> at odds can can (read:do) cause confusion. >> >> From the RhinoMocks wiki (http://ayende.com/Wiki/Rhino+Mocks+3.5.ashx) >> >> IMPORTANT: A stub will never cause a test to fail. >> >> >> However... >> >> A post from about a year ago ( >> http://ayende.com/Blog/archive/2008/06/29/Rhino-Mocks-3.5-Design-Decisions-The-role-of-Stub-vs.aspx) >> discusses the role of a stub and a very simple test will demonstrate that in >> fact a Stub can cause a test to fail. >> >> >> [Test] >> public void Stub_and_Assert() >> { >> var stub = MockRepository.GenerateStub<IFoo>(); >> >> stub.AssertWasCalled(x => x.Method(Arg<string>.Is.Anything)); >> } >> >> produces a failure, indicating the method was expected #1 time but was >> called #0. >> >> *What I'm seeing is that the lines between a mock and a stub are >> extremely blurry. I am really struggling with the difference here. I think >> if there is the ambiguity here and that is the direction of the framework, >> let's embrace it and remove the notion of mocks/stubs and call everything >> Fakes (a la Roy O.) and assert on whatever you want. If we want the >> distinction baked into the framework then the distinction should be clear >> (and enforced).* >> >> Tim >> >> -- >> Tim Barcz >> ASPInsider >> http://timbarcz.devlicio.us >> http://www.twitter.com/timbarcz >> >> >> >> > > > > -- Tim Barcz ASPInsider http://timbarcz.devlicio.us http://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 -~----------~----~----~----~------~----~------~--~---
