I'm forced to use TypeMock where I work, and while I feel very uncomfortable with the evil things it lets you get away with (and have witnessed some *massive* abuse of that power) the new faking API is actually quite nice to use. Having one concept to keep in your head - "I'm faking this" - keeps it simple and allows you to focus on the problem at hand rather than how best to use the tool. In my side projects I use Moq these days for this reason - it has a similar focus to it. Rhino Mocks was my first love, and I would still rather use it to have the more natural extension method approach - having to do fakeThing.Object in Moq still bugs me. Personally I'd like to see a small, tightly focused API that does away with all the baggage and moves to a single notion of "fakes" or whatever the nomenclature du jour might be.
On Mon, Aug 24, 2009 at 8:19 PM, Tim Barcz<[email protected]> wrote: > I'd like to see a thinner surface but one that still provides all the > features (give me more with less...) > > I think in general the lines between mocks and stubs are blurry, not just in > RhinoMocks but in people's minds. I tell people always use Stubs, only use > mocks when checking interaction. Jimmy Bogard says always use mocks, never > use stubs. > > I'd like to see something like: > > var fake = Fake.Create<IFoo> > > // expectation > fake.Expect(x=>x.Method()).Return("hello") > > // stub > fake.Stub(x=>x.Method()).Return("hello") > > // strict mock > var fake = Fake.Create<IFoo>.AsStrict > > Those are my thoughts.... > > 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 Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
