Hello, I've enjoyed using Rhino.Mocks, but I had a couple things I would like to add to this discussion.
I like the idea of having version 4.0 as a separate namespace if it's going to break compatibility. I really think that Rhino.Mocks should add the capability using the profiler API and thus the ability to mock out static functions and other non-virtual functions. I realize that brings about a philosophical debate to many people about the right way to code. However, when I'm using a component or library that is out of my control and I need the ability to mock it, then not being able to gets in the way of me getting my work done and having unit testable code. On Sep 1, 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… --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
