Hm, listen to my DNR from Oredev about Rhino Mocks.Specifically, to Carl asking what Rhino Mocks is.
On Tue, Sep 1, 2009 at 10:09 PM, Tim Barcz <[email protected]> wrote: > ....ah...yes I see...we need a Wizard (very good, let's do it!). > > > On Tue, Sep 1, 2009 at 1:56 PM, Jason Meckley <[email protected]>wrote: > >> >> Alex, a simpler API would lower the entry level. But lets also not >> forget (as much as we want to) the entry level for .net development is >> "where is the IDE Wizard?" >> that said moving the old syntax to another namespace still makes the >> option available and can confuse the developer. If you're trying to >> reduce the surface area, and reduce friction; move the old >> functionality to another assembly (Rhino.Mocks.OldSchool.dll). This >> way the user needs 2 assemblies for backwards compatibility. moving >> forward (4.1?) Rhino.Mocks.OldSchool.dll is dropped altogether. >> >> On Sep 1, 12:55 pm, Alex McMahon <[email protected]> wrote: >> > I think a good goal is to reduce the barrier to entry of Rhino Mocks. >> > I see a lot of questions being asked on the mailing list that are a >> > result of new users trying to get to grips with the tooling and >> > wandering down paths that lead to the same common errors, e.g. mixing >> > different syntaxes together. >> > >> > If we can achieve this without losing any functionality or syntaxes >> > then that seems ok, but the default and easiest exploration path >> > should be limited to the chosen syntax (AAA). >> > >> > Perhaps this means moving all the classes relating to older syntaxes >> > into a different namespace (Rhino.Mocks.Interop? probably a better >> > name would be needed) so people can upgrade to 4.0 and keep everything >> > the same by just adding a using to this namespace. Then in the main >> > namespace (Rhino.Mocks) we keep as small a surface area so that a new >> > user could pretty much get started just by using intellisense. >> > >> > When a user starts using the Interop namespace and getting it all >> > mixed up leading to asking the questions (as I'm sure some will) we >> > can say "The Interop namespace is designed only for backwards >> > compatibility scenarios, please use the Rhino.Mocks.Fake class and >> seehttp://ayende.com/wiki/Rhino+Mocks.ashxfor usage details" >> > >> > 2009/9/1 Tim Barcz <[email protected]>: >> > >> > > Do we need to kill backwards compatibility. I'm working on a >> patch/spike >> > > where the class Fake is used which really just calls MockRepository >> under >> > > the hood? >> > >> > > Thoughts? >> > >> > > On Tue, Sep 1, 2009 at 10:56 AM, Ayende Rahien <[email protected]> >> wrote: >> > >> > >> This is a blog post that would show up day after tomorrow, I am >> posting it >> > >> here to get some traction in the mailing list before we make it >> really >> > >> public. >> > >> > >> Well, now that Rhino Mocks 3.6 is out of the way, we need to think >> about >> > >> what the next version will look like. >> > >> > >> Initially, I thought to match Rhino Mocks 4.0 to the .NET 4.0 release >> and >> > >> support mocking dynamic variables, but while this is still on the >> planning >> > >> board, I think that it is much more important to stop and take a look >> at >> > >> where Rhino Mocks is now and where we would like it to be. >> > >> > >> I started Rhino Mocks about 5 years ago, and the codebase has stood >> well >> > >> in the test of time. There aren’t any nasty places and we can keep >> releasing >> > >> new features with no major issues. >> > >> > >> However, 5 years ago the community perception of mocking was >> different >> > >> than what it is now. Rhino Mocks hasn’t really changed significantly >> since >> > >> it 1.1 days, for that matter, you can take a code base using Rhino >> Mocks for >> > >> .Net 1.1 and move it to Rhino Mocks 3.6 with no issues. >> > >> > >> But one of the most frequent complaints that I have heard is that >> Rhino >> > >> Mocks API has became too complex over the years, there are too many >> options >> > >> and knobs that you can turn. I know that my own style of interaction >> testing >> > >> has changed as well. >> > >> > >> The current plan for Rhino Mocks 4.0 is that we will break backward >> > >> compatibility in a big way. That means that we are going to >> drastically >> > >> simplify everything in the framework. >> > >> > >> We are still discussing this in the mailing list, but currently it >> looks >> > >> like we will go with the following route: >> > >> > >> Kill the dynamic, strict, partial and stub terminology. No one cares. >> It >> > >> is a fake. >> > >> Remove the record / playback API. The AAA method is much simpler. >> > >> Simplify mocking options, aiming at moving as much as possible from >> > >> expectation style to assert style. >> > >> Keep as much of the current capabilities as we can. That means that >> if >> > >> Rhino Mocks was able to support a scenario, it should still support >> it for >> > >> the 4.0 version, hopefully in a simpler fashion. >> > >> > >> The end result is putting Rhino Mocks on an API diet. I am looking >> for >> > >> help in doing this, both in terms of suggested syntax and in terms of >> actual >> > >> patches. >> > >> > >> You are welcome to contribute… >> > >> > > -- >> > > Tim Barcz >> > > Microsoft ASPInsider >> > >http://timbarcz.devlicio.us >> > >http://www.twitter.com/timbarcz >> >> > > > -- > Tim Barcz > Microsoft 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 -~----------~----~----~----~------~----~------~--~---
