I had the pleasure recently to do some unit testing work for some foundational classes (not, not TDD, but still…) and decided to quit stubbing and start Mocking.  One of our colleagues recommended Moq, and that’s the one we went with.  Moq is great, and I totally dig the mocking approach and am astonished yet again at how little I’ve actually known about real unit testing.  One little problem I ran into with Moq, however, led me to another little gem (Hint: Moles).  See, I was unit testing already-existing classes, and the idea of refactoring to make them more unit test friendly was not part of the plan.  Luckily nearly all the classes either directly supported dependency injection, so getting around dependencies in most cases was quite straight forward.  However, there were a few scenarios where I needed to mock out non-virtual methods, or, gasp, static routines.  Turns out Moq does not excel in this department, so I stumbled upon the awesomeness of Microsoft Moles.  Moles fit right into my scenario allowing me to swap out non-virtual and/or static routines that were inherent dependencies in the execution path of the routines I was unit testing.  For example, if you are writing a unit test for the routine “Foo” and within that routine, there is a call to a static method that actually *does* something outside the scope of the unit test (ie, *it* has dependencies on something), then you can use Moles to basically swap out that routine (essentially hijack it and force that code to use whatever you tell it to use – perhaps replacing the static method with a do-nothing routine).

So, if you are unit testing, or perhaps even new to unit testing, I encourage you to consider looking at both of these tools.  Perhaps start out with Moq, but if you encounter the same limitation, check out Moles.

J