This blog post is a copy of information I gathered at the time many moons ago for Moles and may well be inaccurate now but here for reference. I was using Visual Studio 2010 at the time.
Moles best practice
When moling, follow this best practice:
- Use moles as a last resort. Stubs are the preference to mocks. If the object you want to mock has an interface or base class create a stub!
- Always mole your external classes, even constructors! Even empty ones. Do not rely on other code not changing for your tests to pass.
- The preference is for system DLLs to not be moled unless absolutely necessary. You really want them to work as they normally should. Plus you don't want loads of moles for loads of .NET interactions. Moling a system DLL would be required if you must interact with, configuration, files or some other external dependency.
- Observer Locals
Use booleans when testing for when a property is get or set and when methods are called. For when collections are built, a count should be adequate. Then Assert at the end of the test.
- Use Stubs rather than Moles wherever possible as moles have reportedly worse performance. There is no study to confirm this or even how badly the performance is. It is just in said in the Moles documentation. http://research.microsoft.com/en-us/projects/pex/documentation.aspx
- Consider putting reuseable mock methods into own class with the naming convention as <ClassName>Mock, e.g. DateTimeMock.
- A mock method should ideally handle only one method in the object even if you mock all the other ones. This allows better reuse across the tests as some paths will not require the mocked methods.
- Use our custom the ParameterValidator class (which throws a ParameterValidatorException) to check mole parameters instead of Assertions to keep to the principle of one Assert per test. This will also not confuse anyone when tests break.
Moles knowledge base
Add missing mole.
How do you mole an object in System.dll/mscorlib.dll?
Mole the DLL as normal but add the following attributes to the xml file:
Mole complains about COM object
Moling Interop.Vixcom needed the "Embed interop Types" property on the dll set to false to stop Moles generator complaining.
InvalidOperationException: Dynamic operations can only be performed in homogenous AppDomain
Change a value in the Moles config file:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.Moles.VsHost.x86.exe.config
<legacyCasPolicy enabled="true" />
<legacyCasPolicy enabled="false" />
TFS build shows a Moles warning
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1360): Could not resolve this reference. Could not locate the assembly "mscorlib.Moles, Version=220.127.116.11, Culture=neutral, PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
- Unload the test roject. Right-click on the unloaded project and select "Edit ... proj"
- Replace this reference
<Reference Include="mscorlib.Moles.dll, Version=18.104.22.168, Culture=neutral,
PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL" />
<Reference Include="mscorlib.Moles.dll, Version=22.214.171.124, Culture=neutral, PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL" />
- With this
- <Reference Condition="Exists('..\..\MolesAssemblies\mscorlib.Moles.dll')" Include="mscorlib.Moles.dll">
<Reference Condition="Exists('..\..\MolesAssemblies\mscorlib.Moles.dll')" Include="mscorlib.Moles.dll">
- Note: The moles hint path assumes the test project is referencing from a "bin\Debug" folder.
- Note: If you get local compile warnings of "The referenced component 'mscorlib.Moles' could not be
found." then ignore it.