·Detour implementation. The mole types rely on runtime code rewriting, which is implemented by a CLR profiler. The stub types simply rely on virtual method dispatch.
·Performance. The runtime code rewriting used by mole types introduces significant performance degradation in execution time. The stub types do not have this performance overhead and are as fast as virtual methods can go.
·Static methods, sealed types. The stub types can only influence methods that can be overridden. Therefore, stub types cannot be used for static methods, non-virtual methods, sealed virtual methods, methods in sealed types, and so on.
·Internal types. Both stub types and mole types can be used with internal types that were made accessible through the [InternalsVisibleTo(…)] attribute.
·Private methods. The mole types can replace private methods if all the types on the method signature are visible.
·Static Constructor and Finalizers. Moles can “erase” static constructors and finalizers for user given types.
·Deployment. The mole types require a CLR profiler to be installed on the machine to execute the tests. This might be an issue if the build machine cannot be modified. The stub types are self-contained and will work properly as long as the Moles framework assemblies are present.
·Interfaces and abstract methods. Stub types provide implementations of interfaces and abstract methods that can be used in testing. Mole types cannot instrument interfaces and abstract methods, because they do not have method bodies.
In general, we recommend that you use stub types to isolate from dependencies. This can be achieved by hiding the components behind interfaces. Mole types can be used to isolate from third-party components that do not provide a testable API.