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…