Understanding The Big Difference Between Stubs And Moles

I am still retrofitting a whole bunch of unit tests at a client using Pex and Moles. As we have seen in past posts, Pex and Moles are great for creating parameterized unit tests and mock data!

In a conference call this morning, it got brought up that similar to other mocking products in SharePoint development, why all the classes are just not moled (I still don’t know if this is the right verbiage!) and why the heck I am using so many stubs :) . It turned into a lengthy discussion that I wanted to sum up so I can point to this post later!

Firstly, a stub (or more accurately, the stubs framework) is basically a nifty means of static code generation. What this means is a dissimilarity in expectation structured expression trees for testing (the code is generated at runtime [dynamic]). Now, stubs find utility because of efficiency and declarative coverage, the performance benefits coming from the leveraging of virtual method dispatch. Virtual method dispatch is generally more efficient since it already has the this pointer ready to go. When calling through a delegate the this pointer has to be fetched from the delegate. Booooo hisssssss. :) So it’s fast! In the terms of components, Moles lean on the CLR (the profiler more specifically) for the test generation, whereas stubs will use the virtual method approach to overload stuff.

Now, even though the efficiency is pretty impressive, this indubitably doesn’t mean that stubs should continually be used over moles. That is best established by what exactly is being tested. So approach may heavily vary. But, a rule of thumb is if you can use stubs, suck it up, deal with the code bloat, and enjoy the performance benefits! It is always important to still consider what you are testing however, you want to make sure that the unit testing is targeted and is not inadvertently testing unnecessary classes and promotes proper testing!


Runtime Instance From Mole Types

This is more of a quick tip than anything in regards to moles. When using moles, sometimes you might be find yourself executing a safe cast, or trying to, between your Mole and runtime instance type. Why would this happen? Well consider the following simple code:

TypeX x = ReturnAType() as TypeX;

Now this is a problem with moles, because the typecast will fail resulting in x being null. However, the solution is just to stick with variant types when using Moled types, each moled type will have a property representing the Instance (the property is actually the MoledType.Instance property) which will expose the runtime instance. The cool part is the case is built automagically by the compiler :-)