.NET Framework Archives -

Source Code:

In this post I’ll discuss about writing unit tests using Pex and Moles. Pex and Moles are Visual Studio 2010 Power Tools that help Unit Testing .NET applications.

Pex automatically generates test suites with high code coverage. Right from the Visual Studio code editor, Pex finds interesting input-output values of your methods, which you can save as a small test suite with high code coverage.
Moles allows to replace any .NET method with a delegate. Moles supports unit testing by providing isolation by way of detours and stubs i.e. Generate a Mole type from the original type and redefine its behavior using delegates.

Pex and Moles can be downloaded from http://research.microsoft.com/en-us/projects/pex/.

I’ll explain the steps to generate unit tests for a project which calls a WCF service. Pex will be used to generate unit tests. Moles will be generated to isolate the external dependency(WCF proxy) and behavior will be redefined using delegates.

The projects inside the sample solution are

DemoService: This project is a WCF Service.
DemoLibrary: This project is a Class library and service reference to DemoService has been added. Unit tests will be generated for this project.
ConsoleApp: This project is a Console application.
DemoLibrary.Tests: This is a Test project and contains unit tests for DemoLibrary.

The solution structure is displayed below

DemoLibrary calls DemoService though proxy as displayed in the Layer diagram

I’ll now discuss in brief the code snippets of each project

WCF Service(DemoService): This service provided only a single operation

[ServiceContract]
public interface IDemoService
{
    [OperationContract]
    string Search(string criteria);
}

WCF Service Client(DemoLibrary): It calls the Search method of DemoService through proxy as displayed below

public string GetResults(string s)
{
    DemoServiceReference.DemoServiceClient client = null;
 
    try
    {
        client = new DemoServiceReference.DemoServiceClient();
        client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;                
        client.ChannelFactory.Credentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
        s = client.Search(s);
        return s;
    }
    finally
    {
        if (client != null)
        {
            if (client.State == CommunicationState.Opened)
            {
                client.Close();
            }
            else if (client.State == CommunicationState.Faulted)
            {
                client.Abort();
            }
        }
    }
}

Unit Testing DemoLibrary using Pex and Moles:

In order to generate unit tests for WCF Service Client(DemoLibrary) project the steps are

Right click on the class for which unit tests needs to be generated and click “Create Parameterized Unit Tests” as displayed below
A popup will be displayed where Filters and Output can be modified. Click Ok to go to next step.

A new test project will be created. Test Class and Test stub will be be added to this project as displayed below

/// <summary>This class contains parameterized unit tests for Search</summary>
[PexClass(typeof(Search))]
[PexAllowedExceptionFromTypeUnderTest(typeof(InvalidOperationException))]
[PexAllowedExceptionFromTypeUnderTest(typeof(ArgumentException), AcceptExceptionSubtypes = true)]
[TestClass]
public partial class SearchTest
{
    /// <summary>Test stub for GetResults(String)</summary>
    [PexMethod]
    public string GetResults([PexAssumeUnderTest]Search target, string s)
    {
        string result = target.GetResults1(s);
        return result;
        // TODO: add assertions to method SearchTest.GetResults(Search, String)
    }
}

There is an external dependency(GetResults makes a service call though the WCF Proxy) so “Run Pex Explorations” will not generate unit tests as displayed below
In order to isolate the external dependency we need to generate Moles before running Pex Explorations. Moles will be generated for DemoLibrary and System.ServiceModel assemblies and behavior will be redefined using delegates. There are two ways to generate a mole for an assembly. I’ll show you both the approaches
1. Visual Studio: This is the easiest way.
  1. Right click on the reference and generate Moles for that assembly as displayed below.
  2. A .Moles file will be added to the project. Build the project and Moles.dll will be added to MolesAssemblies folder as displayed below .
2. Command Prompt: Moles can be generated from the command prompt.
  1. Run the moles.exe and specify the assembly path for which Moles needs to be created.
  2. Copy the generated assembly to the Project and add reference to it.
Similarly as explained above we need to generate Moles for System.ServiceModel assembly. For Visual Studio 2010 SP1 this may fail with error message “The type or namespace name ‘IHttpCookieContainerManager’ does not exist in the namespace ‘ssm::System.ServiceModel.Channels’ (are you missing an assembly reference?)”. This step however works fine for Visual Studio 2010. The fix is to exclude the type i.e. ‘IHttpCookieContainerManager’ from StubGeneration as displayed below

The next step is to Mock the Service call(redefine behavior using delegates) and add Asserts as displayed in code snippets below

/// <summary>Test stub for GetResults(String)</summary>
[PexMethod]
public string GetResults([PexAssumeUnderTest]Search target, string s)
{
    MockWCFService<IDemoService>();
 
    MDemoServiceClient.Constructor = (var1) =>
       new MDemoServiceClient { };
 
    MDemoServiceClient.AllInstances.SearchString = (var1, var2) =>
    {
        return "Result";
    };
 
    string result = target.GetResults(s);
    PexAssert.IsNotNullOrEmpty(result);
    PexAssert.AreEqual(result, "Result");
    return result;            
}
 
/// <summary>
/// Mocks the WCF service.
/// </summary>
private void MockWCFService<TService>() where TService : class
{
    MClientCredentials.Constructor = (var1) =>
        new MClientCredentials()
        {
            WindowsGet = () => { return new MWindowsClientCredential(); }
        };
 
    MClientCredentials.AllInstances.WindowsGet = (var1) =>
    {
        return new MWindowsClientCredential();
    };
 
    MWindowsClientCredential.AllInstances.ClientCredentialGet = (var1) =>
    {
        return new System.Net.NetworkCredential();
    };
 
    MWindowsClientCredential.AllInstances.ClientCredentialSetNetworkCredential = (var1, var2) => { };
 
    MWindowsClientCredential.AllInstances.AllowNtlmGet = (var1) => { return true; };
 
    MWindowsClientCredential.AllInstances.AllowNtlmSetBoolean = (var1, var2) => { };
 
    MWindowsClientCredential.AllInstances.AllowedImpersonationLevelGet = (var1) => { return System.Security.Principal.TokenImpersonationLevel.Impersonation; };
 
    MWindowsClientCredential.AllInstances.AllowedImpersonationLevelSetTokenImpersonationLevel = (var1, var2) => { };
 
    MChannelFactory.AllInstances.CredentialsGet = (var1) => { return new MClientCredentials(); };
 
    MClientBase<TService>.AllInstances.ClientCredentialsGet = (var1) =>
    {
        return new System.ServiceModel.Description.ClientCredentials();
    };
 
    MClientBase<TService>.AllInstances.ChannelFactoryGet = (var1) =>
    {
        return new MChannelFactory01<TService>();
    };
 
    MClientBase<TService>.AllInstances.StateGet = (var1) =>
    {
        return PexChoose.EnumValue<CommunicationState>("CommunicationState");
    };
 
    MClientBase<TService>.AllInstances.Close = (var1) =>
    { };
 
    MClientBase<TService>.AllInstances.Abort = (var1) =>
    { };              
}

Run Pex Explorations to generate unit tests for GetResults method as displayed below
Unit tests will be added to the Test Class as displayed below
Go to Test View and Run the unit tests as displayed below

Summary:

In a similar way we can extract out external dependencies using Moles and then run Pex Explorations. A few examples of external dependencies can be data layer, UI layer, server calls etc. You can read more about Pex and Moles at http://research.microsoft.com/en-us/projects/pex/.

In this article I’ll discuss about the criteria behind choosing IDisposable, IComponent, Component, MarshalByValueComponent and base Control classes(System.Windows.Form.Control and System.Web.UI.Control) while implementing a Class.

Prior to discussing further I’d like to share the reason behind this article. I ran code analysis in a project code and got a warning that Dispose was not called for a DataSet in the project’s code. I than called the Dispose method for that particular DataSet and this time code analysis executed with zero errors/warnings. Out of curiosity I thought of verifying the use of calling Dispose on DataSet as even though when Dispose was not being called everything was fine. I found that calling Dispose method did nothing as DataSet is a managed object and does not contain unmanaged resources(if I’m wrong please correct me on this). I could verify this as I was able to access/update the DataSet even after Dispose had been called without any “Object Disposed Exception”. FeatureSchema is a typed DataSet as displayed in code snippet below

FeatureSchema fs = Proxy.GetFeatureSchema();

fs.Dispose();

foreach (FeatureSchema.FeatureRow featureRow in fs.Feature.Rows)

//Do procesing on dataset

I went one step further to find the reason behind having Dispose method in DataSet/DataTable and the reason was inheritance as DataSet/DataTable inherits from System.ComponentModel.MarshalByValueComponent class. The reason DataSet/DataTable inherits MarshalByValueComponent class so that it can be designable i.e. used on a design surface. Thus DataSet/DataTable has dispose method even though it doesn’t clean up the resources. DataSet/DataTable call GC.SuppressFinalize in the constructor to prevent the Garbage Collector from calling Object.Finalize on an object that does not require it.

This can be proved by the code snippet displayed below

I have a typed dataset FeatureSchema and I have added a destructor to it. I have excluded the code that was auto generated as I am focusing on finalizers only

public partial class FeatureSchema : global::System.Data.DataSet

//Added only a destructor to this types dataset. I have excluded all other code

// as I am focusing on finalizers

~FeatureSchema ()

As displayed below I am loading data to this typed dataset from an .xml file

//I am just loading the data into this typed dataset

FeatureSchema schema = new FeatureSchema();

schema.ReadXml(featureSchemaFile, XmlReadMode.Auto);

As DataSet calls GC.SuppressFinalize in the constructor Object.Finalize will not be called by the Garbage Collector. This can be verified by placing a break point on the destructor and you will find that it is not getting called.

Now I will call GC.ReRegisterForFinalize as displayed in the code snippet below

FeatureSchema schema = new FeatureSchema();

GC.ReRegisterForFinalize(schema);

schema.ReadXml(featureSchemaFile, XmlReadMode.Auto);

Calling GC.ReRegisterForFinalize will register the object for finalization. I am doing this as I know that DataSet calls GC.SuppressFinalize in the constructor. Now the code will break on the break point which I placed on the destructor at some random time i.e. when GC will execute the “GC Finalizer Thread”.

This verifies the need of calling GC.SuppressFinalize from the constructor of DataSet/DataTable to prevent the garbage collector from requesting finalization.

Even though Dispose in DataSet/DataTable does nothing we should not ignore it and stick to the .Net coding practices otherwise in future versions of Framework things may break. Please do correct me if I am wrong. This concludes the reason behind this article.

I’ll continue with the main theme of article. The guidelines for implementers are

IDisposable:

If a class uses external resources and will not be used on a design surface IDisposable interface has to be implemented directly or indirectly e.g. System.Drawing.Font class etc.
IComponent:

If a class will be used on a design surface IComponent interface has be implemented directly or indirectly. IComponent implements IDisposable e.g. System.Web.UI.Control class etc.
Component:

If a class will be used on a design surface and is Marshalled by reference then it has to derive from Component class e.g. System.Timers.Timer class etc.
MarshalByValueComponent:

If a class will be used on a design surface and is Marshalled by value then it has to derive from MarshalByValueComponent class e.g. DataSet, DataTable etc.
Control:

If a class will be used on a design surface and provides a user interface then this class is a control and has to derive from System.Windows.Form.Control or System.Web.UI.Control e.g. System.Windows.Forms.Button etc.

The above discussion does not apply to WPF. The WPF Designer architecture is significantly different from the Windows Forms Designer architecture, which is characterized by the IComponent interface and the System.ComponentModel namespace. The WPF Designer architecture retains the TypeConverter and TypeDescriptor classes from the Windows Forms Designer object model. Most other aspects of the WPF Designer architecture are different. For more information please read Comparing the Windows Forms Designer Framework to the WPF Designer Framework

Refrences: http://msdn.microsoft.com/en-us/library/0b1dk63b.aspx

del.icio.us Tags: .NET,.NET Framework,IDisposable,IComponent,Component,MarshalByValueComponent,Control,Windows Forms,ASP.NET,DataSet,DataTable,Garbage Collector,GC

Tag: .NET Framework

How to use Pex and Moles to generate unit tests for a project having external dependency(WCF Proxy) using Visual Studio 2010 SP1

Summary:

How to choose between IDisposable, IComponent, Component, MarshalByValueComponent and Control while implementing a Class

IDisposable:

IComponent:

Component:

MarshalByValueComponent:

Control: