A month ago I did a post about the TypeMock mocking framework and the nice people at TypeMock were kind enough to give me a 1 year license for their software. Although I haven't really played with it as much as I hoped/ would have liked I have done a bit with it and though I'd share some thoughts.
To have a bit of a base line I was doing my playing with both Typemock and RhinoMocks, just to have an example against a good free mocking framework.
Where Typemock rocks
The most exciting aspect of Typemock for me is that I can mock anything (well, nearly anything, you can't mock things from within mscorlib), and I mean anything. With the SharePoint aspect TypeMock really advertises that you can mock the SharePoint libraries as they are, meaning that you don't need source code access or anything.
What do I mean by this? Well take RhinoMocks for example. RhinoMocks is built on top of the Castle projects DynamicProxy2 component. This means that if you're wanting to set up expected returns your methods are required to be virtual. This can be a problem if you're mocking an external framework (ie - SharePoint).
But because TypeMock doesn't used DynamicProxy2 you don't have this limitation.
So with the demos which I was watching and reading with TypeMock on SharePoint it got me thinking, could I mock Umbraco? And you know what, I can!
This is really exciting, when I was developing the Umbraco Interaction Layer I really wanted it to be unit tested, but due to limitations within Umbraco this mean I wasn't able to use something like RhinoMocks, because I needed to setup expected returns on method calls which weren't virtual (although I could download the source and modify that myself it defeats the concept of supporting a standard Umbraco release).
So I got playing with TypeMock and low and behold I was able to set up some basic mocks to make fake data types!
The code is currently POC-level and won't be going into the CodePlex project (I feel it is unfair that I put a licensed product up when the UIL is a free product), but still it is a very interesting concept and something I plan to look deeper into.
I also have found that TypeMock can be a whole lot easier to set up mock returns, because the parameters are completely ignored when making a method call you can be a bit more careless in your mock setup.
Lastly TypeMocks ability to mock the construction of objects without public constructors is really nifty. Again this has great advantages when mocking with external libraries like SharePoint and Umbraco.
Where TypeMock doesn't rock
Although I stated that I like that I don't have to really worry about the parameters being passed into the method this is also a bit of a drawback. If you had a method that you want different returns depending on the method input (say, something doing a calculation) this is something that I so far haven't been able to work out how to achieve.
By contrast this can be done in RhinoMocks as you need to provide a valid method parameter that you will then use when calling for the mock.
Is it worth the money?
This is a difficult question to answer, primarily because I haven't played with TypeMock enough. I really think that it's more of a case of "depending what you're doing". I can see that TypeMock is really great if you're wanthing to mock the results from an external library like SharePoint, Umbraco (or I'm sure even SiteCore ;). Also I see TypeMock is great to add mocking after the fact to a project. You may be will into development, many of the project API's are already set up, ready for use but you want to now go down the TDD path (it's never too late to start!). In this case going back and redoing all methods to be virtual is not really viable. But TypeMock's non-reliance on virtual methods for mock results does mean you can achieve TDD without major refactoring.