Rhino Mocks tutorials are long and complicated because Rhino Mocks itself is very complicated and the documention is not great. I love it because it makes refactoring a simple matter. NMock and most other frameworks use strings for member access, which end up scattered throughout your code. This will usually come back to haunt you if you rely on a lot of mocks in your unit tests and you need to change an interface.

Now for the criticism you asked for at the end of your article. I love that you covered interactions and state tests in such a short span, but I think you could improve your writing style by stating what you want to do *before* doing it. You actually made your tutorial less readable and longer than needed by posting that big test class at the top, and then dissecting it line-by-line to explain what each one does. Clearly stating your intent and then showing commented code would be better. If you think it would be helpful to talk about individual members like Record() and Playback() or classes like Expect, write it after the code. Also, your “Getting Started” section is just a paragraph of you admitting that you have no idea what you’re talking about. That’s irrelevant (you’re blogging dude, not doing hard science), and you could have just quoted what you needed from the Rhino Mocks documentation to fill in the gaps for the reader—this is ALWAYS better than guessing. If you start off by saying “this is half-assed and I don’t get it myself” most people will stop reading right there.

As an aside, you should play with the built-in NUnit mock framework (in the NUnit.Mocks assembly in 2.2 or later). If you really are having trouble with the concepts, it’s an incredibly simple and accessible implementation that I’ve used to teach people basic interaction and state testing. Here’s a REALLY short tutorial that will give you the basics: http://www.emxsoftware.com/Mock+object+framework+in+Nunit+2