Ideally, I would like to get some ideas about the desired syntax and capabilities.That will allow us to have better idea about what is needed. I intend to make use of a lot of the RM existing infrastructure, so it is the surface behavior that interests me the most.
On Fri, Sep 4, 2009 at 5:23 PM, Tim Barcz <[email protected]> wrote: > I too am curious on the organizing around this... > > Do we need/want to set up something like tickets or use AgileZen (or other > tools) for project purposes? > > Tim > > > On Fri, Sep 4, 2009 at 3:17 AM, Alex McMahon <[email protected]> wrote: > >> >> Ayende, >> >> When you say "you are welcome to contribute" will you be organising >> this in some way? will there be a list of tasks? >> >> I've not submitted a patch to Rhino Mocks before, but I'd be >> interested in having a go at submitting one for 4.0. >> >> Do you think there will be tasks that could be tackled by someone >> who's not already overly familiar with the code base? >> >> Regards >> Alex McMahon >> >> 2009/9/1 Ayende Rahien <[email protected]>: >> > 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 > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
