Ok, I've heard that I may might be seeing some unit tests that use Moq in my next project. I had only read examples about this mocking framework but no real (or unreal) work with it I did.

I have to admit several things before anything:

• I am a huge fan of RhinoMocks. I think I can use some of the tricks this powerful framework offers and I feel very comfortable with it.
• I have no problem whatsoever with the record/replay model. Having grown in the use of mocking frameworks with Rhino made me familiar very early with it.
• I am as rookie as one can be in the use of the new framework, so maybe my impressions are led by ignorance.
• By the way, I am creating my pet project "test-aside", not test-first, and I am mocking virtual methods in concrete classes; which could explain some of the scenarios I am running into.

Disclaimers in place, let's start..

I like the syntax very much. I am starting to feel more comfortable amongst lambdas than I was before. I still switch back to anonymous delegate from time to time though.

For simple tests it worked flawlessly, but things got weird very soon.

You better pay attention and understand very well the behavior of the mocks. Otherwise you might be as surprised (and do I hate surprises when programming) as I was: it happens than whenever an expectation is set on a mock that was created with the Mock class constructor on a virtual method, the call gets forwarded to the real implementation if the conditions for the parameters are not met. That is perfectly fine with me, in fact I think it should be the behavior. But it took me a while to find out that the reason my mocks were not returning the expected value was the non-strict default behavior of the mocks. It wasn't until I used the MockFactory object (which makes you explicitly set the behavior) that the framework informed me that I had screwed up when I set the expectations.

I still have a problem when setting multiples expectations on an object. It seems to me that it only pays attention to the last expectation recorded. But it does in such a strange way that I am seriously thinking of a bug. I will move away from the nightly build and use the latest stable version and check if I am paying the taxes of alpha software :-p

Another impression I got is that it is quite a young project. And immaturity is not shown in the quality of code or usefulness of it. It is more patent in the amount and quality of documentation and, of course, the size of the community of users. While the user base of RhinoMocks is very, very decent and you can find lots of information about it.

It is still not the case with Moq. But you know what? "Critical mass" on a product is achieved by using the product, so I will fight my desire to get back to my comfort zone and get the thing done with RhinoMocks and I will keep on trying with this framework.

At the end of the day is a pet project and pet projects do no have a tight deadline and I love new toys in the tool-belt.