
Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

For several years now, I have been relying on Microsoft’s Moles for isolating one method from another in my unit tests. Recently I’ve begun to understand that this was not the best approach. I’ll dig into that more in a future post. Having come to this conclusion, I need to start ripping out Moles. Based on the user feedback across the web, and the powerful Lambda expression syntax I’ve grown used to, I’ve chosen MoQ as my replacement. Now for an exercise…
Assuming that you are already sold on the notion of automated testing, it can be useful to put a little thought into how projects will be setup. There are many approaches to this; my approach is based on experience, the wisdom in xUnit Test Patterns, and standard coding best practices. I will try to keep this language agnostic, though my examples will be in C#.
I wonder how many others didn't think to scroll down further on the Pex download page, and find this link? Visual Studio 2010 Moles - Isolation Framework for .NET. Moles is available for free, while the full Pex environment requires MSDN.
Once again I've learned the hard way that it pays to read the release notes. After installing Pex v0.91.x, suddenly I was having trouble running my tests in a particular solution. It has been driving me nuts - Visual Studio was throwing "object reference not set to an instance of an object" errors every time I tried to run tests, and the Test View was refusing to load any test names.
Finally, I noticed that I had a few tests that were still instrumented with HostType "pex" instead of "moles". I changed these around, and still got the error. Closed Visual Studio, restarted, and voìla, the tests can run, and Test View is populated again.