binary dreams

a world of 1s and 0s

How to use Moles

This blog post is a copy of information I gathered at the time many moons ago for Moles and may well

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

MoleNotImplementedException thrown

Fix

Add missing mole.

How do you mole an object in System.dll/mscorlib.dll?

Fix

Mole the DLL as normal but add the following attributes to the xml file:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">

<Assembly Name="System" ExportedTypes="true" ReflectionOnly="true" />

</Moles>

There are some special types that cannot be moled. There is currently no list of specific types that are listed as unmoleable.

From http://stackoverflow.com/questions/8144653/moling-system-dll.

Moved a class, namespace changed and not moling that class?

Fix

Clean the solution and rebuild.

Mole complains about COM object

Fix

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

Fix

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

From:

  <runtime>
     <legacyCasPolicy enabled="true" />
  </runtime>

To:

  <runtime>
     <legacyCasPolicy enabled="false" />
  </runtime>

Information

http://social.msdn.microsoft.com/Forums/en/pex/thread/0a931fc1-9049-482a-bf2d-5499ccf65b82

TFS build shows a Moles warning

Example

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=4.0.0.0, 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.

Fix

  • Unload the test roject. Right-click on the unloaded project and select "Edit ... proj"
  • Replace this reference
    <Reference Include="mscorlib.Moles.dll, Version=4.0.0.0, Culture=neutral, 
    PublicKeyToken=0ae41878053f6703, processorArchitecture=MSIL"
     />  
  • With this
    1. <Reference Condition="Exists('..\..\MolesAssemblies\mscorlib.Moles.dll')" Include="mscorlib.Moles.dll">   
    2.   <SpecificVersion>False</SpecificVersion>   
    3.   <HintPath>..\..\MolesAssemblies\mscorlib.Moles.dll</HintPath>  
    4. </Reference>  
  • 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.

How to use C# properties with SOLID class design principles

It wasn&#39;t so long ago I was using properties without any consideration to how they SHOULD be used. I&#39;m going to show you how you can use them properly with the help of SOLID Class Design Principles.

It wasn't so long ago I was using C# properties without any consideration to how they SHOULD be used. I'm going to show you how you can use them properly with the help of SOLID Class Design Principles.

Case 1:

This is a typical class you might have written.

public class Person
{
public string Forename { get; set; }
public string Surname { get; set; }
public Person() {}
}

STOP! Using public setters here with the person attributes breaks the Single Responsibility Principle (SRP) because the class has more than one reason to change. The class breaks this with two reasons - Forename and Surname.

To fix this, make the setters of those properties private and create an Update method like so:

public class Person
{
public string Forename { get; private set; }
public string Surname { get; private set; }
public void Update(string forename, string surname)
{
Forename = forename;
Surname = surname;
}
}

Now the class has one reason to change rather than two.

In general an object should not have it's state changed unless it was changed by an action. Remember OO design is about data hiding, how an objects attribute changes is of no concern to its consumer. Only the object needs to know how it changes.

Case 2:

How would you check the object is valid? Check each property like this:

var person = new Person();
person.Update("forename", "surname");
if (person.Surname != null && person.Forename != null)
{
SaveToDatabase(person);
}

STOP! This breaks the Dependency Inversion Principle (DIP) - Depend on abstractions not on concretions. We need to create a validation method to abstract us from the attributes. The properties should not be checked outside of the class but from inside the class.

Lets rewrite it.

Create an interface

public interface IValidate
{
	bool IsValid();
}

Now change the Person class.

public class Person : IValidate
{
public string Forename { get; private set; }
public string Surname { get; private set; }
public void Update(string forename, string surname)
{
Forename = forename;
Surname = surname;
}
public bool IsValid()
{
return (Forename != null) && (Surname != null);
}
}

With the Person class rewritten you would use it like so.

var person = new Person();
person.Update("forename", "surname");
if (person.IsPersonValid())
{
SaveToDatabase(person);
}