SlimRhinoMocks sounds like a good idea. (although not with the MS naming standard of 'Slim' perhaps!)
For now perhaps the line in the wiki: > IMPORTANT: A stub will never cause a test to fail. should be changed to make it more clear: "A stub will never cause a test to fail, unless assertions are specified for the stub" Looking more closely at the wiki page there seems to be other discrepancies: "but those *expectations will never be verified*. A stub's properties will automatically behave like normal properties, and you *can't set expectations * on them." Is this still true? aren't we saying that you can set (and verify) expectations on a stub? 2009/8/24 Ayende Rahien <[email protected]> > 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 >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
