Alex,First thing to do is to decide where we are going, that is why this discussion is so important. Next stage is to get everyone's input and then start working. And yes, I do mean submitting code. I believe that if you'll take a look at the Rhino Mocks codebase, you'll be able to get yourself familiarized in a short while. It is a good codebase, even if I say so myself.
On Fri, Sep 4, 2009 at 11: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… > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
