ploeh blog : Component Development

SqlExpressDatabaseInstaller

ploeh — Wed, 17 Sep 2008 22:57:06 GMT

When unit testing data access components, I prefer to test against run-time components that match the target environment as closely as possible. In other words, if the data access component targets SQL Server 2008, I prefer to test against a SQL Server 2008 database. In a number of earlier posts, I've described this approach, where the database is being automatically created as an Immutable Shared Fixture.

While I prefer this approach, it has a few disadvantages that may or may not force you to look for alternatives:

The entire test suite must at least have sysadmin privileges on the SQL Server instance, because otherwise it's not possible to create and delete databases. Since unit testing mostly focus on the functional aspects of a SUT, this may not be that important, but it's certainly more desirable if unit tests can execute under least privilege.
Some run-time environments where the test suite will execute may not have SQL Server installed - e.g. my team's current build server doesn't have SQL Server installed, so even though my machines have, that's not going to help me if I want my tests to be running as part of the Build Verification Tests.

A reasonable alternative to SQL Server is SQL Server Express, and particularly its User Instance feature, which allows you to create a file-based database on the fly and still have full sysadmin privileges on just that database. Besides, in my particular case, our build server doesn't have SQL Server, but it does have SQL Server Express.

Since SQL Server Express uses the same relational data engine as SQL Server, it's a pretty decent alternative.

When I set up the database as part of my Immutable Shared Fixture, I want to create a one-off User Instance that can be deleted afterwards. An .mdf file in my temp folder does the trick.

As usual, I will set up and tear down the Immutable Shared Fixture using Installers. To do this, I need an Installer than can create and delete a SQL Server Express User Instance. As usual, I create a dedicated Installer for this purpose:

public class SqlExpressDatabaseInstaller : Installer

    public override void Install(IDictionary stateSaver)

        this.ExecuteNonQuery("CREATE DATABASE [{0}] ON PRIMARY (NAME='{1}', FILENAME='{2}')");

        base.Install(stateSaver);

    public override void Uninstall(IDictionary savedState)

        SqlConnection.ClearAllPools();

        string dropStatement =

            "IF EXISTS (SELECT [name] FROM sys.databases WHERE [name] = '{0}') BEGIN DROP DATABASE [{0}] END";

        this.ExecuteNonQuery(dropStatement);

        base.Uninstall(savedState);

    private void ExecuteNonQuery(string sqlStatement)

        string databaseFileName = this.Context.Parameters["DatabaseFileName"];

        string logicalFileName = Path.GetFileName(databaseFileName);

        SqlConnectionStringBuilder scsb = new SqlConnectionStringBuilder();

        scsb.DataSource = @".\SQLEXPRESS";

        scsb.IntegratedSecurity = true;

        scsb.UserInstance = true;

        using (SqlConnection conn = new SqlConnection(scsb.ConnectionString))

            using (SqlCommand cmd =

                new SqlCommand(

                    string.Format(sqlStatement, databaseFileName, logicalFileName, databaseFileName),

                    conn))

                conn.Open();

                cmd.ExecuteNonQuery();

If you compare it with SqlDatabaseInstaller, you will probably notice a lot of similarities. They both use SQL DDL statements to create and drop the database, but since SQL Express User Instances are file-based, we need to specify the file name explicitly in the CREATE statement.

Another difference from SqlDatabaseInstaller lies in the way the connection string is being built. First of all, SqlExpressDatabaseInstaller expects a file name from the Context instead of a full connection string. Subsequently, it specifies SQL Express as the DataSource and sets the UserInstance property to true.

Because of the similarities between SqlDatabaseInstaller and SqlExpressDatabaseInstaller, the obvious next step would be to merge the functionality of these to classes into a single class, but I haven't really had the need for that yet, although I may do so in the future.

Before dropping the database, I invoke SqlConnection.ClearAllPools to clear all connection pools; if I don't do that, the file will be locked and cannot be deleted. In my original post on data access component testing, I recommended disabling connection pooling for testing, but as one of my readers was so kind to point out, SqlConnection.ClearAllPools is a much better alternative, so I'm now using that exclusively. Had I posted SqlDatabaseInstaller today, I would have included a call to SqlConnection.ClearAllPools in its Uninstall method as well, so these two database Installers really are quite similar.

SqlScriptListInstaller

ploeh — Wed, 12 Dec 2007 01:01:00 GMT

The last of a series of SQL Server-related database Installers is a little helper that simply makes it easier to bundle several SQL scripts together as part of a single Installer package. Instead of mixing several SqlScriptInstallers together with other Installers, you can group them together in a single container:

public class SqlScriptListInstaller : Installer

    public SqlScriptListInstaller(

        IEnumerable<SqlScriptInstaller> scriptInstallers)

        foreach (SqlScriptInstaller scriptInstaller

            in scriptInstallers)

            this.Installers.Add(scriptInstaller);

This Installer simply holds a list of SqlScriptInstallers in its Installers property. When Install is called, the Install method will be invoked on each of the contained Installers; likewise for Uninstall.

This is in no way the most essential of the three SQL Server-related Installers, but is still a nice convenience at times.

SqlScriptInstaller

ploeh — Sat, 01 Dec 2007 11:23:00 GMT

In my previous post I described a general-purpose Installer that can be used to create a SQL Server database during installation (and delete it again during uninstallation). As promised, this post picks up where the other stopped to describe another Installer that can execute arbitrary T-SQL scripts against a database.

You would typically use this SqlScriptInstaller in conjunction with the SqlDatabaseInstaller to execute T-SQL scripts against the database that SqlDatabaseInstaller creates.

One of the challenges of executing T-SQL scripts from managed code lies in the frequently encountered need to support SQLCMD commands such as GO (as you may know, GO is not a T-SQL keyword, so if you try to execute a T-SQL script with GO commands from ADO.NET, you will get an exception). While you could write a simple parser that splits up a script according to its GO commands, a more correct and full-featured solution is to use SQL Server Management Objects (SMO) to execute the script.

SMO is available if you have installed the SQL Server Client Tools. If that constraint is not acceptable, you will have to write your own SQLCMD parser and use ADO.NET, but you should still be able to reuse the principles outlined below.

SqlScriptInstaller uses SMO to execute T-SQL scripts:

public class SqlScriptInstaller : Installer

    private readonly string sqlScript_;

    public SqlScriptInstaller(string sqlScript)

        this.sqlScript_ = sqlScript;

    public SqlScriptInstaller(Stream sqlStream)

        using (StreamReader sr = new StreamReader(sqlStream))

            this.sqlScript_ = sr.ReadToEnd();

    public override void Install(IDictionary stateSaver)

        string connectionString = this.Context.Parameters["ConnectionString"];

        using (SqlConnection conn = new SqlConnection(connectionString))

            ServerConnection serverConn = new ServerConnection(conn);

            Server sqlServer = new Server(serverConn);

            sqlServer.ConnectionContext.ExecuteNonQuery(this.sqlScript_);

        base.Install(stateSaver);

The serverConn variable is an instance of Microsoft.SqlServer.Management.Common.ServerConnection and sqlServer an instance of Microsoft.SqlServer.Management.Smo.Server, so you will need to add references to Microsoft.SqlServer.ConnectionInfo and Microsoft.SqlServer.Smo, respectively. The ExecuteNonQuery method on the ConnectionContext understands SQLCMD commands, so your script can have as many GO commands as you need.

Notice that the SqlScriptInstaller uses the same ConnectionString parameter as SqlDatabaseInstaller, but this time uses the connection string unmodified.

In this incarnation, I haven't implemented Uninstall, since I tend to rely on SqlDatabaseInstaller to simply delete the database during uninstallation, but strictly speaking, to be truly general-purpose, SqlScriptInstaller should be able to work independently. If this feature is needed, it would be simple to implement Uninstall by executing a second, compensating T-SQL script, but I'll leave that as an exercise to the reader :)

By supplying T-SQL scripts to SqlScriptInstaller you can use SQL DDL statements to populate the database schema in a database you previously created with SqlDatabaseInstaller.

SqlDatabaseInstaller

ploeh — Thu, 29 Nov 2007 14:28:00 GMT

Installers provide a consistent way of implementing automated setup logic for an application, and as I previously wrote, they also work admirably well for setting up test fixtures. The BCL, however, only contains a limited amount of pre-built Installers, so if you need to install something else than performance counters, event logs, MSMQ queues, or Windows services, you need to define your own.

One very common installation requirement is the need to install a database as part of application installation. For SQL Server, the database itself will most likely be defined as a set of T-SQL DDL scripts, but you need some code to execute those scripts if you need to do this as part of an automated installation, and a few general-purpose Installers serve this purpose nicely.

In this post, I'll describe the first of such Installers, and subsequent posts will describe the rest.

The purpose of the SqlDatabaseInstaller is simply to create the database itself. Uninstallation conversely deletes the database.

public class SqlDatabaseInstaller : Installer

    public override void Install(IDictionary stateSaver)

        this.ExecuteNonQuery("CREATE DATABASE {0}");

        base.Install(stateSaver);

    public override void Uninstall(IDictionary savedState)

        base.Uninstall(savedState);

        string dropStatement =

            "IF EXISTS (SELECT [name] FROM sys.databases WHERE [name] = '{0}') BEGIN DROP DATABASE {0} END";

        this.ExecuteNonQuery(dropStatement);

    private void ExecuteNonQuery(string sqlStatement)

        string connectionString = this.Context.Parameters["ConnectionString"];

        SqlConnectionStringBuilder scsb =

            new SqlConnectionStringBuilder(connectionString);

        string databaseName = scsb.InitialCatalog;

        scsb.InitialCatalog = "master";

        using (SqlConnection conn = new SqlConnection(scsb.ConnectionString))

            using (SqlCommand cmd =

                new SqlCommand(string.Format(sqlStatement, databaseName), conn))

                conn.Open();

                cmd.ExecuteNonQuery();

The tricky part here is the ExecuteNonQuery method - not that executing a non-query is in itself difficult, but obtaining the connection string turns out to be non-trivial. Since it wouldn't be a general-purpose Installer if it contained a hard-coded connection string, one must be supplied via the Installer's Context, so there's a bit of convention built into SqlDatabaseInstaller:

The user of the SqlDatabaseInstaller is expected to supply a value for the ConnectionString parameter. When the Installer is being executed from managed code, this parameter value must be added to its Context's Parameters collection; when the Installer is being executed via InstallUtil, the connection string must be supplied as a command-line parameter.
The supplied connection string is expected to point to the database being created. While this may seem counter-intuitive, it makes a lot of sense if you see several database-related Installers bundled together, since all subsequent Installers will use the unmodified connection string with the correct database to populate its schema, etc.

You can override Installer.HelpText to supply this information to the user, like this:

public override string HelpText

get

        StringBuilder sb = new StringBuilder();

        sb.AppendLine("/ConnectionString (required)");

        sb.AppendLine(" Example:");

        sb.AppendLine(" InstallUtil /ConnectionString=\"Server=localhost; Database=MyDB; Integrated Security=true;\"");

        return sb.ToString();

This would display the help text mixed in with the general help on options if you write InstallUtil [assembly] /? on a command line.

You may also want to add some error handling to create a more helpful error message in case the user forgets to supply the connection string, or it isn't correctly formatted.

While this post described a general-purpose Installer that creates a SQL Server database upon installation, and deletes it again upon uninstallation, future posts will describe other Installers for populating the database with schema and data.

Reasons For Isolation

ploeh — Wed, 30 May 2007 13:22:00 GMT

Object-oriented applications above some level of complexity are almost always modelled as a layered architecture. While the typical three-layer architecture remains the most widely known, n-layer architecture is also often utilized. Here's a typical design almost anyone can create (in Visio or Power Point, that is):

There seems to be an almost universal agreement that layering is the correct things to do, but do you know why layering is considered such an attractive design feature?

When I ask this question of people, most answer that this enables them to replace a certain implementation with another implementation. What's even more interesting is that the typical implementation of this design is best illustrated like this:

No clear separation of logic is implemented, modules tend to trample over each others' domains, but worst of all, there's a strong hierarchy of dependencies in place: Most assemblies have dependencies on other assemblies in the solution, and few of of the projects can be compiled without also compiling all the dependent projects. The only projects that can typically compiled without volatile dependencies are the ones in the bottom layer, but those are the ones you most need to be independent of.

When confronted with this fact, most project members don't think this is a big deal, since the ability to replace one implementation with another isn't important in their current project. To paraphrase a typical response: "Yes, it would be nice to be able to replace our relational database with XML files without recompiling, but we are never going to need this, so why bother?"

This attitude suggests to me that people are missing the point.

The reason why layering is important is because each module must be able to exist in isolation. This means that it should be possible to compile a project without having to load any other projects containing volatile dependencies. If you ever find that you have to load 35 projects into your solution to compile a single project, you are doing something wrong. Ideally, you should be able to define a self-contained solution containing a small subset of your projects; about five projects, and certainly no more than ten.

If the ability to replace one implementation with another is not the sole reason for isolation, then what is?

Personally, I can think of at least three independent reasons:

It's nice to have the ability to replace one implementation with another. Yes, I know I just implied that it's wrong to think that you don't need isolation if you don't need this feature, but I didn't say that this ability isn't valuable in some projects. In many Enterprise/Line of Business applications, this feature may not matter, but other application types (such as shrink-wrapped software) often offer some extensibility model where such a feature could be very valuable to customers.
In large projects, it enables development teams to work independently of each other. One team can work on the data access layer while another team works on the business logic. Even when it's not important that you can replace your complex data access component when you deploy the application, it's very valuable for the business logic team to be able to replace the data access component with a simple, temporary implementation. This will allow the business logic team to work without being blocked by the data access team.
Unit testing becomes possible. By definition, a unit is (a part of) a module isolated from its dependencies. When you can replace one implementation of a dependency with another, you can also replace it with a test double. Since unit testing is by far the most cost-effective type of test, this property alone makes isolation very attractive.

If just a single of these reasons seems valuable to you, isolation should be one of your top priorities as you are implementing your design.

Unit Testing Activity CodeDOM Serializers

ploeh — Thu, 05 Apr 2007 21:41:00 GMT

Windows Workflow Foundation (WF) defines workflows as object graphs. To save or compile workflow definitions, these object graphs must be serialized, and WF supports serialization to both XAML and code. Similar to other components, WF utilizes the .NET design-time framework for serialization and deserialization of objects. Serializing objects to code is done using CodeDomSerializer-derived classes.

In WF, the base CodeDOM serializer is ActivityCodeDomSerializer, and if you want to unit test your custom CodeDOM serializer for a custom activity, you can use the general approach I have earlier described. As it turns out, unit testing WF Activity CodeDOM serializers is simpler than unit testing components in general, since the base WF classes are already doing some of the work for you. You will still need to implement a designer loader for testing purposes, but you don't need to mess with a fake implementation of ITypeResolutionService.

Let's say that I wish to unit test my custom serialization logic for this activity and its corresponding serializer:

[DesignerSerializer(typeof(MyActivityCodeDomSerializer),

    typeof(CodeDomSerializer))]

public class MyActivity : Activity

    // Implementation goes here

public class MyActivityCodeDomSerializer :

    ActivityCodeDomSerializer

    // Implementation goes here

As you can tell, I've omitted the implementations of both Activity and serializer, since these are not important for this example. Just like the general case, the first thing to do is to create a designer loader that only exists for unit testing purposes. However, instead of deriving from CodeDomDesignerLoader, this class should derive from WorkflowDesignerLoader:

internal class FakeCodeDomDesignerLoader : WorkflowDesignerLoader

    public override string FileName

        get { return "Fake"; }

    public override TextReader GetFileReader(string filePath)

        throw new NotImplementedException();

    public override TextWriter GetFileWriter(string filePath)

        throw new NotImplementedException();

WorkflowDesignerLoader is an abstract class, so it's necessary to override its abstract members, but as you can tell, I haven't done much in that regard. In this case, GetFileReader and GetFileWriter is never called, and although FileName is invoked, the return value is not used for anything that affects the unit test, so I'm just returning a hard-coded string.

When you call BeginLoad on a DesignSurface with this loader (which I'll do in the unit test), PerformLoad will be called, so I have overridden this method to define a default root component:

protected override void PerformLoad(

    IDesignerSerializationManager serializationManager)

    base.PerformLoad(serializationManager);

    CompositeActivity rootActivity = new SequenceActivity();

    this.AddActivityToDesigner(rootActivity);

In this case, the root component will always be a SequenceActivity; this corresponds to opening a new sequential workflow in the Visual Studio designer. You can now add other Activities to the root sequential workflow from the unit test, as I will demonstrate later.

To retrieve the serialized code, the designer loader must be flushed. While flushing, PerformFlush is called, so I override this method to capture the serialized code and save it in a private field:

private CodeStatementCollection codeStatements_;

protected override void PerformFlush(

    IDesignerSerializationManager serializationManager)

    base.PerformFlush(serializationManager);

    ActivityCodeDomSerializer serializer =

        new ActivityCodeDomSerializer();

    this.codeStatements_ =

        (CodeStatementCollection)serializer.Serialize(

        serializationManager, this.LoaderHost.RootComponent);

To retrieve the serialized code from a unit test, I implement a simple method that returns the code statements (recall that calling Flush causes PerformFlush to be called):

internal CodeStatementCollection GetCodeStatements()

    this.Flush();

    return this.codeStatements_;

With FakeCodeDomDesignerLoader in place, it's now fairly straightforward to write a unit test that exercises the custom serializer that's associated with MyActivity:

[TestMethod]

public void MyTestCase()

    FakeCodeDomDesignerLoader loader =

        new FakeCodeDomDesignerLoader();

    DesignSurface surface = new DesignSurface();

    surface.BeginLoad(loader);

    IDesignerHost host =

        (IDesignerHost)surface.GetService(typeof(IDesignerHost));

    MyActivity ma =

        (MyActivity)host.CreateComponent(typeof(MyActivity),

        "ma");

    ((SequenceActivity)host.RootComponent).Activities.Add(ma);

    CodeStatementCollection codeStatements =

        loader.GetCodeStatements();

    // Perform validation of code statements

As with the general approach, the first thing to do is to create an instance of the designer loader. Then I create a new DesignSurface which is going to host the SequenceActivity root component that I can then add an instance of MyActivity to. Calling BeginLoad on the DesignSurface caused PerformLoad to be called on the FakeCodeDomDesignerLoader instance, which then creates the SequenceActivity and adds it as the root component.

The next step is to retrieve an instance of IDesignerHost, which can then be used to create an instance of MyActivity. Creating MyActivity instances this way ensures that any designers, editors and serializers (in this case, MyActivityCodeDomSerializer) is loaded and initialized correctly.

The newly created MyActivity instance is then added to the root component, i.e. the sequential workflow.

Getting the serialized code statements is then as simple as calling GetCodeStatements. This returns a CodeStatementCollection instance, and you can then use the principles outlined in my former article to validate that your custom serializer created the expected code statements.

Validating Code Serialized by CodeDomDesignerLoaders

ploeh — Sun, 01 Apr 2007 17:10:00 GMT

A while back I wrote about unit testing component serializers, but I left the task of validating the generated code against an expected result up to the reader. The approach outlined in that article was to retrieve the generated code as a string and compare it to an expected string. While this is certainly a relatively easy and intuitive approach, experience has meanwhile taught me that it leaves something to be desired with regards to robustness.

Let's revisit the original example from the former article, where I'm serializing a control called MyControl. The generated code typically looks something like this:

//------------------------------------------------------------------------------

// <auto-generated>

//     This code was generated by a tool.

//     Runtime Version:2.0.50727.312

//

//     Changes to this file may cause incorrect behavior and will be lost if

//     the code is regenerated.

// </auto-generated>

//------------------------------------------------------------------------------

namespace TestNamespace

    public class Form1 : System.Windows.Forms.Form

        private ReadOnlyCollectionSerialization.MyControl myControl1;

        private Form1()

            this.InitializeComponent();

        private void InitializeComponent()

            this.myControl1 = new ReadOnlyCollectionSerialization.MyControl();

            this.SuspendLayout();

//

            // myControl1

//

            this.myControl1.Location = new System.Drawing.Point(0, 0);

            this.myControl1.Name = "myControl1";

            this.myControl1.Size = new System.Drawing.Size(150, 150);

            this.myControl1.TabIndex = 0;

//

            // Form1

//

            this.ClientSize = new System.Drawing.Size(284, 264);

            this.Controls.Add(this.myControl1);

            this.Name = "Form1";

            this.ResumeLayout(false);

There are a couple of potential issues with performing a strict string comparison against this expected code:

The version of the .NET framework appears in the initial comment. As I discovered when I moved to the x64 platform, the build and revision numbers are not the same as on x86, which suddenly caused my unit tests to fail.
In principle, this form of testing is very sensitive to white spaces. When you compare two strings, white spaces count, but in code, a lot of the white space doesn't matter. Since you essentially care about the functionality of the serialized code, and not the white space, such a strict comparison is not warranted. Although I must admit that this has never been an issue for me, this has always bothered me. What if a future service pack for .NET changes the serialization behavior such that there's only one, and not two, empty lines between the namespace declaration and the type declaration in the above example? Surely, this would have no impact on the functionality of the serialized code, but it would cause a string-comparing test to fail.

A more robust approach would be to validate against the CodeDom itself. To do this, I first need to add a new method to my TestCodeDomDesignerLoader class (I'll refer you to my original article for an introduction to this class):

internal CodeCompileUnit GetCodeCompileUnit()

    this.Flush();

    return this.compileUnit_;

Instead of serializing the code using a CodeDomProvider, I simply return the CodeCompileUnit generated by the serializer. It's now possible to test against this CodeCompileUnit, and I'll show you how by walking you through a continuation of the example from my original article. In that example, the test SerializeBasicMyControl calls loader.GetCode to get the code as a string. Instead of doing that, I'll retrieve the CodeCompileUnit:

CodeCompileUnit compileUnit = loader.GetCodeCompileUnit();

The compileUnit variable will now contain a complete, language-neutral representation of the code. If the serializer works correctly, this code should correspond to the auto-generated code above. It even contains the comments, but since these have no impact on functionality, I'll ignore them, so the first thing I need to test is that the namespace is called TestNamespace, and there's only a single namespace in the CodeCompileUnit:

CodeNamespaceCollection namespaces = compileUnit.Namespaces;

Assert.AreEqual<int>(1, namespaces.Count);

Assert.AreEqual<string>("TestNamespace", namespaces[0].Name);

The next thing to validate is that there's only a single type in the code, and that it's called Form1:

CodeTypeDeclarationCollection types = namespaces[0].Types;

Assert.AreEqual<int>(1, types.Count);

Assert.AreEqual<string>("Form1", types[0].Name);

Besides validating the name of the generated type, it's also relevant to validate that Form1 derives from Form, and that it doesn't derive from other types (i.e. implement any interfaces):

CodeTypeReferenceCollection baseTypes = types[0].BaseTypes;

Assert.AreEqual<int>(1, baseTypes.Count);

Assert.AreEqual<string>("System.Windows.Forms.Form",

    baseTypes[0].BaseType);

At this point, I could choose to continue with validating the the code contains a private field called myControl1, that the Form1 constructor is defined, and that it calls the InitializeComponent method, but I'll skip that for now, since the most relevant part to test is the InitializeComponent method itself. To validate that method, I must ensure that it exists and get a reference to it. There are three members of Form1: the myControl1 field, the constructor, and the InitializeComponent method, so it's necessary to loop through the type's members to find it:

CodeTypeMemberCollection members = types[0].Members;
CodeMemberMethod method = null;
foreach (CodeTypeMember member in members)
{
    method = member as CodeMemberMethod;
    if ((method != null) && 
        (method.Name == "InitializeComponent"))
    {
        break;
    }
    method = null;
}
Assert.IsNotNull(method);

Now that I have the method definition, I also have all the code statements it contains:

CodeStatementCollection statements = method.Statements;

The validation that has occurred until this point validates a part of the serialization code that typically doesn't have anything to do with what you are trying to test. In this example, the purpose of the test is to validate the custom serializer that serializes instances of MyControl; the relevant code will be placed within the InitializeComponent method. The namespace, name of the Form, etc. is actually defined in the TestCodeDomDesignerLoader's Parse method, so you might consider refactoring all of this validation code into a method of TestCodeDomDesignerLoader, and let it return the CodeStatementCollection from the InitializeComponent method. This would allow you to focus on the essential part of each test case.

In this test, I'll just validate that the first serialized line of code is as expected, to give you an idea of how this can be done. This line of code should be an assignment, where a new instance of MyControl is assigned to the myControl1 field:

Assert.IsInstanceOfType(statements[0], typeof(CodeAssignStatement));

CodeAssignStatement assignStatement = (CodeAssignStatement)statements[0];

This first part just checks that the statement is an assignment. Next, I'll validate that the left side of the assignment is a reference to this.myControl1:

Assert.IsInstanceOfType(assignStatement.Left,

    typeof(CodeFieldReferenceExpression));

CodeFieldReferenceExpression fieldReference =

    (CodeFieldReferenceExpression)assignStatement.Left;

Assert.AreEqual<string>("myControl1", fieldReference.FieldName);

Assert.IsInstanceOfType(fieldReference.TargetObject,

    typeof(CodeThisReferenceExpression));

The right side of the expression is a bit more complex, since I need to validate that the expression is creating a new instance, and that the created instance is of type MyControl. It's easy to validate that the expresion creates a new instance:

Assert.IsInstanceOfType(assignStatement.Right,

    typeof(CodeObjectCreateExpression));

CodeObjectCreateExpression objectCreate =

    (CodeObjectCreateExpression)assignStatement.Right;

To validate that a MyControl instance is created using the default constructor (i.e. that no parameters are used in the constructor), I add this:

Assert.IsInstanceOfType(objectCreate.CreateType,

    typeof(CodeTypeReference));

CodeTypeReference codeType =

    (CodeTypeReference)objectCreate.CreateType;

Assert.AreEqual<string>("ReadOnlyCollectionSerialization.MyControl",

    codeType.BaseType);

Assert.AreEqual<int>(0, objectCreate.Parameters.Count);

This is quite a lot of validation code to verify a single line of code!

As I started out by stating, validating against a string is a far more intuitive approach, but the one outlined here is more robust. Fortunately, the large portion of the validation code that occurs before the validation of InitializeComponent can be reused across multiple test cases.

Additionally, just because you could, in theory, validate every single statement in the InitializeComponent method, it doesn't mean that you should. Typically, when you unit test component serializers, you only care about specific lines of code, since most of the generated code is rather trivial. If this is the case, you can skip all the trivial statements and find only those you care about, and then validate those.

How To Dispose Members From Forms

ploeh — Thu, 10 Aug 2006 12:22:00 GMT

When you create a new Form (or UserControl for that matter), Visual Studio creates it as a partial class, with the designer-generated code going into the *.Designer.cs file. One other piece of code that also goes into the designer code is an override of System.ComponentModel.Component.Dispose(bool), which contains the code to dispose the form and its contained components. It always looks like this:

protected override void Dispose(bool disposing)
{
    if (disposing && (components != null))
    {
        components.Dispose();
    }
    base.Dispose(disposing);
}

It's a bit unfortunate that this method is being overridden, because it makes it more difficult to add your own dispose logic to the form, since you can't override the method once more in the same class - remember that the form code that you control is only part of the class definition. You could obviously edit the designer file directly, but that's not recommended.

Then what can you do if you need to perform some extra dispose logic in your Form? This need can easily arrive if one of your member variables implement IDisposable, in which case you really should dispose of it when the Form disposes. Imagine you have the following IDisposable class:

public class MyDisposable : IDisposable
{
    private string message_;
 
    public MyDisposable(string message)
    {
        this.message_ = message;
    }
 
    #region IDisposable Members
 
    public void Dispose()
    {
        MessageBox.Show(this.message_);
    }
 
    #endregion
}

You now want to have a MyDisposable member variable in your Form, and you need to dispose of it when the Form disposes:

public partial class MyForm : Form
{
    private MyDisposable myDisposable_;
 
    public MyForm()
    {
        InitializeComponent();
 
        this.myDisposable_ =
            new MyDisposable("Goodbye, World");
    }
}

When you run the application and close the Form, the Form is being disposed, but you never see the goodbye message because myDisposable_ is not disposed. The Dispose method in the designer code handles the dispose logic for the form, and it knows nothing about the myDisposable_ member variable.

It does, however, Dispose of its components member, and since this is an IContainer, the problem would be solved if you could add myDisposable_ to the container. Unfortunately, IContainer only accepts IComponent instances, and if you may not want to implement IComponent on MyDisposable.

Part of the contract of IComponent is that an implementation must have a default constructor, and for API design reasons, you may not find that acceptable for your IDisposable type - for some reason, I don't think that's an acceptable change for MyDisposable.

What you can do, however, is to add an instance of this little class to the container:

internal class Disposer : Component
{
    private Action<bool> dispose_;
 
    internal Disposer(Action<bool> disposeCallback)
    {
        this.dispose_ = disposeCallback;
    }
 
    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
 
        this.dispose_(disposing);
    }
}

From your Form code, you'll need to wire up a new instance of Disposer with a delegate which will contain the real dispose logic. When used in MyForm, it now looks like this:

public partial class MyForm : Form
{
    private MyDisposable myDisposable_;
 
    public MyForm()
    {
        InitializeComponent();
 
        this.myDisposable_ =
            new MyDisposable("Goodbye, World");
        this.components.Add(new Disposer(this.OnDispose));
    }
 
    private void OnDispose(bool disposing)
    {
        this.myDisposable_.Dispose();
    }
}

Notice that I have added a new Disposer instance that points back to the new OnDispose method, which then implements all the dispose logic not handled by the designer code. Now, when I run the application and close the Form, I get the expected MessageBox.

This technique is generally usable whenever you need to dispose of a member variable, but otherwise can't because the designer code already overrides the Dispose method. However, I only recommend this approach if your member variable doesn't also implement IComponent.

If the you have control over the member variable's class and don't mind having a default constructor, I recommend that you instead implement IComponent (the easiest way to do that is by deriving from System.ComponentModel.Component like I did with the Disposer class). This will generally give you a nicer design-time experience, since you can now just drag the component from the toolbox to the design surface, and the designer (Visual Studio) will automatically add it to the components member variable, and thus it will be disposed together with all the other components in the container.

Both approaches also work if you are creating a UserControl, although there, you'll probably need to instantiate the components member variable yourself.

A Faster TestTypeResolutionService

ploeh — Tue, 28 Mar 2006 00:16:00 GMT

In February, I wrote about unit testing CodeDomSerializers, but although it was a good initial attempt, there was room for improvement (as I also described in the article). Back then, my main priority was just to get my unit tests working, so other issues were less important to me at the time.

Since then, I've used this method quite a bit, and although I've been generally happy with it, test performance was not good. Each serialization test caused my CPU utilization to jump to 100% and took perhaps 5-10 seconds to perform. When you have a dozen of these tests, running a test suite takes several minutes, which works against the goal of agile development that you should refactor and run unit tests, refactor and run unit tests, etc.

I knew exactly from were my performance issue originated: The GetType method of the TestTypeResolutionService loops through all referenced assemblies looking for a type with the specified type name. This is quite an expensive operation, as some of the referenced assemblies (like mscorlib and System) contain thousands of types.

However, often the name input parameter contains the assembly qualified type name, and if this is the case, Type.GetType is quite a lot faster. Using Type.GetType as the first attempt to resolve the type, and only looping through referenced assemblies as a second attempt dramatically improves test performance. Here's the updated method:

public Type GetType(string name, bool throwOnError,
    bool ignoreCase)
{
    Type returnType = Type.GetType(name, false, ignoreCase);
    if (returnType != null)
    {
        return returnType;
    }
 
    AssemblyName[] assemblyNames =
        Assembly.GetExecutingAssembly().
        GetReferencedAssemblies();
    foreach (AssemblyName an in assemblyNames)
    {
        Assembly a = Assembly.Load(an);
        Type[] types = a.GetTypes();
        foreach (Type t in types)
        {
            if (t.FullName == name)
            {
                this.cachedTypes_[name] = t;
                return t;
            }
        }
    }
 
    if (throwOnError)
    {
        throw new ArgumentException();
    }
    return null;
}

Type.GetType is called with the throwOnError parameter set to false, which causes the method to return null if the type could not be resolved. This simple change has caused my serialization tests to run 5-15 times faster than before, and running the whole test suite is now something that takes approximately 10 seconds.

If you find it difficult to reproduce the TestTypeResolutionService class from my disparate blog entries, I've included it as an attachment to this post.

Serializing Read-Only Collections to Code

ploeh — Sat, 18 Feb 2006 16:02:00 GMT

In some cases, a Component or Control may have the need to contain a read-only collection of complex objects. Additionally, although you don't want to enable a developer to change the collection itself at design time, you still want to make it possible for the developer to edit the items in the collection.

Creating such a collection is not very difficult, but it turns out that the standard CodeDOM serializer for the component doesn't serialize the collection, so the next time the developer loads the component, all the changes are gone. This is because the standard CodeDomSerializer classes don't know how to reference the collection items; the default way is to create new instances of the collection items and add them to the collection, but this isn't possible in this case, since the collection is read-only.

You can still achieve the desired result by creating a custom serializer for the component, and here I'll show you how.

Consider this example Control:

[DesignerSerializer(typeof(MyControlCodeDomSerializer),
    typeof(CodeDomSerializer))]
public partial class MyControl : UserControl
{
    private MyReadOnlyCollection<MyClass> readOnlyClasses_;
    private List<MyClass> writableClasses_;
 
    public MyControl()
    {
        this.InitializeComponent();
 
        this.writableClasses_ = new List<MyClass>();
        this.readOnlyClasses_ =
            new MyReadOnlyCollection<MyClass>
            (this.writableClasses_);
 
        this.writableClasses_.Add(new MyClass());
        this.writableClasses_.Add(new MyClass());
    }
 
    public MyReadOnlyCollection<MyClass> ReadOnlyClasses
    {
        get { return this.readOnlyClasses_; }
    }
}

This control exposes a single read-only collection as a property. For simplicity, this collection only contains two items, but in a real-world case, other logic in the control would probably add or remove items internally. Although the collection itself can't be edited by external callers (you can't add or remove items), it's perfectly possible and legal to reference and edit the existing items in the collection. I'll show you what I mean in a minute, but for completeness, let's first list the MyClass class:

public class MyClass
{
    private int myInt_;
    private string myString_;
 
    internal MyClass()
    {
    }
 
    [DefaultValue(0)]
    public int MyInt
    {
        get { return this.myInt_; }
        set { this.myInt_ = value; }
    }
 
    [DefaultValue(null)]
    public string MyString
    {
        get { return this.myString_; }
        set { this.myString_ = value; }
    }
}

Referencing and editing one of the MyClass instances in the control is straightforward. If the name of a MyControl instance is mc, the following code assigns the number 10 to the first element in the collection:

mc.ReadOnlyClasses[0].MyInt = 10;

Although you can do this from code, or from within the Visual Studio designer, the default CodeDOM serializer doesn't serialize this value, so the next time you load the control, the element's MyInt property will have the default value of 0.

A solution to this challenge is to associate a custom serializer to the control, and as you can tell from the code above, the MyControl class has a DesignerSerializer attribute which defines a custom CodDOM serializer for the control; if that attribute had not been present, or if the serializer isn't implemented correctly, the read-only collection will never be serialized.

However, before we look at MyControlCodeDomSerializer, we need to define how the serialized code should look. My first take on this was to serialize code like this:

this.myControl1.ReadOnlyClasses[0].MyInt = 1;

This compiles and works at run-time, but doesn't work at design-time! This happens because the designer infrastructure interprets the angle brackets as an array indexer (CodeArrayIndexerExpression) instead of an indexer property (CodeIndexerExpression). At this time, I haven't been able to figure out if this can be fixed (but if anyone knows, please leave a message), so the workaround is to define a method on the collection class which enables you to access an item in a manner which isn't syntactically ambiguous. The collection class is very simple:

public class MyReadOnlyCollection<T> : ReadOnlyCollection<T>
{
    public MyReadOnlyCollection(IList<T> list)
        : base(list)
    {
    }
 
    [EditorBrowsable(EditorBrowsableState.Never)]
    public T GetItemAt(int index)
    {
        return this[index];
    }
}

When using this collection class, code can now be serialized like this:

this.myControl1.ReadOnlyClasses.GetItemAt(0).MyInt = 1;

Note that the GetItemAt method is hidden from Intellisense by its EditorBrowsable attribute. Using a custom collection class is obviously a limitation in usability of this approach, but the rest of the code in this post would work similarly if it turns out to be possible to indicate to the design-time environment that the angle brackets in this case should be interpreted as an indexer property.

Let's now turn to the MyControlCodeDomSerializer class, which derives from System.ComponentModel.Design.Serialization.CodeDomSerializer. To make it serialize the desired code, I override its Serialize method:

public override object Serialize
    (IDesignerSerializationManager manager,
    object value)
{
    CodeDomSerializer serializer =
        manager.GetSerializer(value.GetType().BaseType,
        typeof(CodeDomSerializer))
        as CodeDomSerializer;
 
    object codeObject = serializer.Serialize(manager,
        value);
 
    CodeStatementCollection codeStatements =
        codeObject as CodeStatementCollection;
    MyControl mc = value as MyControl;
 
    if ((codeStatements != null) && (mc != null))
    {
        this.SerializeCollectionProperty(manager,
            codeStatements, mc);
    }
 
    return codeObject;
}

Initially, I extract the serializer for the value's base type and use that to serialize the object. This creates all the standard code statements, such as a creation statement for the component, setting of the Name, Size, and other properties, etc. This is the collection of code statements that I intend to append with the read-only collection code, and this is done (partly) by the SerializeCollectionProperty method:

private void SerializeCollectionProperty
    (IDesignerSerializationManager manager,
    CodeStatementCollection codeStatements,
    MyControl mc)
{
    CodeExpression myControlExp =
        this.GetExpression(manager, mc);
    CodePropertyReferenceExpression colPropExp =
        new CodePropertyReferenceExpression
        (myControlExp, "ReadOnlyClasses");
 
    for (int i = 0; i < mc.ReadOnlyClasses.Count; i++)
    {
        MyControlCodeDomSerializer.SerializeMyClass
            (manager, codeStatements, mc, colPropExp,
            i);
    }
}

This method just sets up some expressions for the SerializeMyClass method, which does the real work. It uses the the base class' GetExpression method to retrieve an expression for the MyControl instance. This will typically be an expression that serializes to something like this.myControl1. It then creates an expression representing the ReadOnlyClasses property of MyControl. For every item in the collection, the method then delegates the real work to the SerializeMyClass method:

private static void SerializeMyClass
    (IDesignerSerializationManager manager,
    CodeStatementCollection codeStatements,
    MyControl mc,
    CodePropertyReferenceExpression colPropExp,
    int i)
{
    MyClass currentMC = mc.ReadOnlyClasses[i];
    CodeMethodInvokeExpression currentMCExp =
        new CodeMethodInvokeExpression
        (colPropExp, "GetItemAt",
        new CodePrimitiveExpression(i));
 
    ExpressionContext newContext =
        new ExpressionContext(currentMCExp,
        typeof(MyClass), mc, currentMC);
    manager.Context.Push(newContext);
 
    try
    {
        CodeDomSerializer currentMCSerializer =
            manager.GetSerializer(currentMC.GetType(),
            typeof(CodeDomSerializer))
            as CodeDomSerializer;
        CodeStatementCollection currentMCStmts =
            currentMCSerializer.Serialize(manager,
            currentMC) as CodeStatementCollection;
        foreach (CodeStatement stmt in currentMCStmts)
        {
            codeStatements.Add(stmt);
        }
    }
    finally
    {
        manager.Context.Pop();
    }
}

This is the core of the solution: The first thing to do is to get a reference to the MyClass instance to serialize. For this, we need the real instance, as well as an expression that indicates to the CodeDomProvider which will eventually serialize the code, how that instance should be serialized. In this case, the instance should be serialized as a call to the GetItemAt method (if you still recall that particular discussion above), so I create an expression that references that method with the correct parameter value.

At this point, I could obviously just continue in that vein and create new CodeExpressions for every property of MyClass, but that's a lot of work: For once, I need to take into account such things as each property's DefaultValue attribute so I don't serialize default values; secondly, imagine that MyClass in itself was a deeply nested structure - then I'd need to write complex recursive code to traverse that object graph. Fortunately, the standard CodeDomSerializers can already do this; they just need a little help in figuring out how to serialize the MyClass reference itself.

This is done by creating a new ExpressionContext for the MyClass instance. That ExpressionContext is populated with the expression for the instance (you will recall that this was the call to the GetItemAt method), the type, parent, and the actual instance itself. When this ExpressionContext is pushed on the ContextStack, other serializers will use this pre-populated expression every time they encounter the MyClass instance - instead of creating an expression themselves!

At this point, all that is left is to get a CodeDomSerializer for MyClass, serialize the instance and merge the resulting code statements into the overall collection of code statements for MyControl. Finally, you need to remember to Pop the ContextStack when you are done with the MyClass instance.

To reiterate, this will serialize code like this:

this.myControl1.ReadOnlyClasses.GetItemAt(0).MyInt = 1;
this.myControl1.ReadOnlyClasses.GetItemAt(0).MyString = "ploeh";

Whenever the designer loads code like this into a DesignSurface, the items in the read-only collection will be pre-populated with the correct values.

Obviously, CodeDomSerializer code like this is a bit complex, so you'd want to be able to unit test your code to ensure that it works as intended. To do so, refer to my post about unit testing serializers.

Towards Unit Testing Component Serializers

ploeh — Thu, 16 Feb 2006 23:21:00 GMT

When writing complex components or controls, it is sometimes necessary to implement custom CodeDOM serialization of the control. If the code serialization logic is complex, it would be nice if it was possible to unit test this logic. It's not quite as easy as it may seem, but it can be done, which I will demonstrate in this post.

Consider a custom Windows Forms control:

[DesignerSerializer(typeof(MyControlCodeDomSerializer),
    typeof(CodeDomSerializer))]
public partial class MyControl : UserControl
{
    // Implementation goes here...
}

The actual implementation of MyControl really isn't important for this example, and neither is the designer serializer. The point here is just that MyControl has a custom serializer that I want to unit test.

When you implement a CodeDOM serializer, you typically just override CodeDomSerializer.Serialize(IDesignerSerializationManager, object). Since the default implementation (the one used by Visual Studio) of IDesignerSerializationManager is System.ComponentModel.Design.Serialization.DesignerSerializationManager, and that class has a default constructor, it seems pretty straightforward to just new up an instance of DesignerSerializationManager and pass it to the Serialize method together with an instance of MyControl, and then do Asserts on the return value.

Unfortunately, this doesn't work if you rely on your serializer's base class (CodeDomSerializer) to perform most of the work for you, and you'll typically end up with a return value of null, even if the same code works well when used by Visual Studio.

The problem lies in the .NET designer framework's loosely couple service architecture. Most design-time classes use an IServiceProvider to retrieve an instance of a specific service, and fail gracefully if none could be located. This is what's happening in this case.

To overcome this issue, it's necessary to more fully simulate the design-time environment when running a unit test: We'll create a new DesignSurface and add a MyControl instance to that surface. However, to get at the serialized code, we'll need to add a CodeDomDesignerLoader to the DesignSurface. This is an abstract class, and there are no useful public implementations of it available in the .NET framework, so we'll have to write one ourselves. This may seem like a lot of work, but on the other hand, it's completely reusable code, so you can use that implementation over and over in different unit tests in different projects.

internal class TestCodeDomDesignerLoader
    : CodeDomDesignerLoader
{
    private CodeCompileUnit compileUnit_;
    private CSharpCodeProvider codeDomProvider_;
    private TestTypeResolutionService typeRsSrvc_;
 
    internal TestCodeDomDesignerLoader()
        : base()
    {
        this.codeDomProvider_ = new CSharpCodeProvider();
        this.typeRsSrvc_ = new TestTypeResolutionService();
    }
 
    protected override CodeDomProvider CodeDomProvider
    {
        get { return this.codeDomProvider_; }
    }
 
    protected override CodeCompileUnit Parse()
    {
        DesignSurface ds = new DesignSurface();
        ds.BeginLoad(typeof(Form));
 
        IDesignerHost host =
            ds.GetService(typeof(IDesignerHost))
            as IDesignerHost;
        host.RootComponent.Site.Name = "Form1";
 
        CodeTypeDeclaration designedClass =
            new CodeTypeDeclaration
            (host.RootComponent.Site.Name);
        designedClass.BaseTypes.Add(typeof(Form));
 
        CodeNamespace ns =
            new CodeNamespace("TestNameSpace");
        ns.Types.Add(designedClass);
 
        CodeCompileUnit ccu = new CodeCompileUnit();
        ccu.Namespaces.Add(ns);
 
        return ccu;
    }
 
    protected override ITypeResolutionService
        TypeResolutionService
    {
        get { return this.typeRsSrvc_; }
    }
 
    protected override void Write(CodeCompileUnit unit)
    {
        this.compileUnit_ = unit;
    }
 
    internal string GetCode()
    {
        this.Flush();
 
        CodeGeneratorOptions options =
            new CodeGeneratorOptions();
        options.BracingStyle = "C";
 
        using (StringWriter sw = new StringWriter())
        {
            this.codeDomProvider_.
                GenerateCodeFromCompileUnit
                (this.compileUnit_, sw, options);
            return sw.ToString();
        }
    }
 
    internal object GetServiceInternal(Type serviceType)
    {
        return this.GetService(serviceType);
    }
}

Most of the class is pretty straightforward. The most notable parts are the Parse method, the TypeResolutionService property and the GetCode method.

The Parse method is probably the most complex to understand. When a DesignSurface is instructed to begin loading (as we will do later, in the unit test) it will (among many other things) call the Parse method to load the initial design surface (imagine you had a Windows Form which you already saved and now want to load again). This particular Parse implementation just assumes that you have an initial empty Form, so it creates the necessary CodeDOM objects which corresponds to the code which will create the Form1 class (which derives from Form).

The DesignSurface will use this code to load Form1 into the designer, so you can add more controls (specifically, in this case, MyControl) to it. This is basically similar to what Visual Studio does.

The GetCode method is just a convenience method to create a string from a CodeCompileUnit, and is only meant to be used from the unit test. Calling Flush on the loader causes the Write method to be called with a CodeCompileUnit representing the current state of the DesignSurface (including any controls added to the surface).

The TypeResolutionService property requires a bit more explanation than it may seem to warrant if you just look at it casually. It returns an implementation of ITypeResolutionService, and like with the CodeDomDesignerLoader abstract class, the .NET framework includes no public implementations of this interface. This is the other helper class we need to implement to get things working.

The ITypeResolutionService is used to locate types and assemblies by name. The Designer framework will query this service with a type name to retrieve a Type instance. The name which is used is sometimes an assembly-qualified type name, including assembly, version number, public key token, etc. - in which case Type.GetType can be used. In other cases, however, the name supplied is just a type name with full namespace path, but no assembly information.

For testing purposes, the ITypeResolutionService interface can be implemented like this:

internal class TestTypeResolutionService
    : ITypeResolutionService
{
    private Dictionary<string, Type> cachedTypes_;
 
    internal TestTypeResolutionService()
    {
        this.cachedTypes_ = new Dictionary<string, Type>();
    }
 
    #region ITypeResolutionService Members
 
    public Assembly GetAssembly(AssemblyName name,
        bool throwOnError)
    {
        throw new NotImplementedException();
    }
 
    public Assembly GetAssembly(AssemblyName name)
    {
        throw new NotImplementedException();
    }
 
    public string GetPathOfAssembly(AssemblyName name)
    {
        throw new NotImplementedException();
    }
 
    public Type GetType(string name, bool throwOnError,
        bool ignoreCase)
    {
        AssemblyName[] assemblyNames =
            Assembly.GetExecutingAssembly().
            GetReferencedAssemblies();
        foreach (AssemblyName an in assemblyNames)
        {
            Assembly a = Assembly.Load(an);
            Type[] types = a.GetTypes();
            foreach (Type t in types)
            {
                if (t.FullName == name)
                {
                    this.cachedTypes_[name] = t;
                    return t;
                }
            }
        }
 
        return Type.GetType(name, throwOnError,
            ignoreCase);
    }
 
    public Type GetType(string name, bool throwOnError)
    {
        return this.GetType(name, throwOnError, false);
    }
 
    public Type GetType(string name)
    {
        return this.GetType(name, true);
    }
 
    public void ReferenceAssembly(AssemblyName name)
    {
        throw new NotImplementedException();
    }
 
    #endregion
}

In the current unit testing scenario, assembly information is never requested, so I've just left the assembly-related methods to throw a NotImplementedException if called. If you ever encounter a situation where your test code causes some of these methods to be called, you will have to implement those methods in addition to the type-related methods.

The only code of interest here is the GetType(string, bool, bool) method. It simply loops through all referenced assemblies, searching for a type with a matching name in each assembly. This is a quite expensive operation (there are lots of types), so you will see CPU utilization going to 100% for a little while when this is happening. My weak attempt at optimization (a dictionary of cached types) is not very effective, since an instance of the class only exists for the duration of a single test (I could have used a static dictionary, or a cached instance of TestTypeResolutionService across all tests, but that would violate the principle that each unit test should be fully independent).

With the TestCodeDomDesignerLoader and TestTypeResolutionService classes ready, writing the unit test itself is relatively straightforward:

[TestMethod]
public void SerializeBasicMyControl()
{
    TestCodeDomDesignerLoader loader =
        new TestCodeDomDesignerLoader();
 
    DesignSurface surface = new DesignSurface();
    surface.BeginLoad(loader);
    IDesignerHost host =
        surface.GetService(typeof(IDesignerHost))
        as IDesignerHost;
 
    MyControl mc =
        host.CreateComponent(typeof(MyControl))
        as MyControl;
 
    ((Form)host.RootComponent).Controls.Add(mc);
 
    string serializedCode = loader.GetCode();
 
    // Compare against expected code string here...
}

An instance of TestCodeDomDesignerLoader (which contains an instance of TestTypeResolutionService) is created and added to a new DesignSurface using the BeginLoad method. This will, as I wrote above, cause TestCodeDomDesignerLoader.Parse to be called. The code from the Parse method is used to set up the DesignSurface, so with this particular implementation, the design surface now contains an instance of the Form1 class (which derives from Form).

It is now possible to use the designer's IDesignerHost implementation to create a new instance of the MyControl class. In this example, creating an instance of the class is all I do, but in more advanced tests, I could then begin to set properties and call methods on the control.

Creating the control using IDesignerHost ensures that the control is sited in an environment with all the required services. It is also necessary to add the control to the root component, which in this case is a Form (actually Form1, since that's what I defined in the Parse method).

The last thing to do is call the GetCode convenience method on the designer loader to get a string with all the code.

At this point, I would compare that string with a target string which I've read from a target code file in my test project, but I'll leave that as an exercise to the reader.

This may seem like an overwhelmingly large amount of work to do, but remember that you only ever need to write TestCodeDomDesignerLoader and TestTypeResolutionService once, and you can just copy them from here; notice that I've omitted tons of using statements for clarity, so you'll need to add those yourself, but I'm sure Visual Studio 2005 will be very helpful in this regard. A lot of the classes involved are defined in System.Design, so you will need to add a reference to that assembly.

In my example, the two reusable classes are internal, which doesn't make them that reusable after all. It would be obvious to create them as public classes and put them in a common unit testing utility library.

There are some weak spots in the code here and there. For once, I haven't handled the assembly-related methods in TestTypeResolutionService. Additionally, the GetType method could probably do with a bit of optimization. There may be other areas which need improvement, which is what I've attempted to hint at in the title. This is not the definitive, authoritative article on this subject, but it will get you started.

If your control serialization code is of only intermediate complexity, you will be very happy to have a suite of unit tests which can be used for quality assurance.

Update: My new post about a faster TestTypeResolutionService explains how to improve test performance.

Unit Testing Control Designers

ploeh — Mon, 06 Feb 2006 16:02:00 GMT

One of the inherent problems of control development is that it doesn't lend itself easily to unit testing. After all, you are developing a user interface, and it's necessary to validate that it looks as expected. While that's true, more complex control logic may still benefit from some unit testing.

Recently, I found myself in a situation where I was developing a Windows control with some rather complex design-time logic, and regression errors were beginning to pop op, so I decided to see if I couldn't unit test the control designer after all.

As it turns out, it's not that difficult, and the very loosely coupled service architecture of the .NET design-time framework makes it very easy to simulate design-time behavior outside of Visual Studio.

As usual, an example is the best way to illustrate the point, so consider this simple control:

[Designer(typeof(MyControlDesigner))]
public partial class MyControl : FlowLayoutPanel
{
    public MyControl()
    {
        InitializeComponent();
    }
}

As you can see, the only thing this control does is derive from FlowLayoutPanel and provide its own designer. The idea behind this control is to provide design-time behavior that allows the user to select two or more child controls of the control, right-click on it and select Reverse order.

Here's the initial version of the designer class:

public class MyControlDesigner : ScrollableControlDesigner
{
    private DesignerVerbCollection designerVerbs_;
 
    public MyControlDesigner()
        : base()
    {
        this.designerVerbs_ = new DesignerVerbCollection();
    }
 
    public override DesignerVerbCollection Verbs
    {
        get { return this.designerVerbs_; }
    }
 
    public override void Initialize(IComponent component)
    {
        base.Initialize(component);
 
        IMenuCommandService mcs =
            this.GetService(typeof(IMenuCommandService))
            as IMenuCommandService;
        if (mcs != null)
        {
            DesignerVerb verb =
                new DesignerVerb("Reverse order",
                this.OnReverseOrderInvoked);
            mcs.AddVerb(verb);
            this.designerVerbs_.Add(verb);
        }
    }
 
    private void OnReverseOrderInvoked
        (object sender, EventArgs e)
    {
        throw new NotImplementedException();
    }
}

The order reversing logic isn't yet implemented, but the relevant designer verb is wired up and ready to go. Now it's possible to use test-driven development while implementing the OnReverseOrderInvoked method.

I'll show you the complete unit test first, and then I'll walk you through it:

[TestMethod]
public void ReverseTwo()
{
    StubSite site = new StubSite();
    site.SetService(typeof(IMenuCommandService),
        new StubMenuCommandService());
 
    StubSelectionService selectionService =
        new StubSelectionService();
    site.SetService(typeof(ISelectionService),
        selectionService);
 
    MyControl mc = new MyControl();
    mc.CreateControl();
    mc.Site = site;
 
    MyControlDesigner mcd = new MyControlDesigner();
    mcd.Initialize(mc);
 
    Button button1 = new Button();
    button1.Name = "button1";
    Button button2 = new Button();
    button2.Name = "button2";
    Button button3 = new Button();
    button3.Name = "button3";
 
    mc.Controls.Add(button1);
    mc.Controls.Add(button2);
    mc.Controls.Add(button3);
 
    List<Button> selectedButtons = new List<Button>(2);
    selectedButtons.Add(button2);
    selectedButtons.Add(button3);
 
    selectionService.SetSelectedComponents
        (selectedButtons);
 
    foreach (DesignerVerb verb in mcd.Verbs)
    {
        if ((verb.Text == "Reverse order")
            && (verb.Enabled))
        {
            verb.Invoke();
            break;
        }
    }
 
    Assert.AreEqual<Control>(button1, mc.Controls[0]);
    Assert.AreEqual<Control>(button3, mc.Controls[1]);
    Assert.AreEqual<Control>(button2, mc.Controls[2]);
}

Admittedly, this isn't the shortest unit test I've ever written, but it does perform a very relevant test, and a few of these is much faster than having to manually testing the control again and again.

Let's review the test method. The designer class uses its protected GetService method to obtain a reference to an IMenuCommandService implementation. This behavior is implemented in System.ComponentModel.Design.ComponentDesigner (from which MyControlDesigner ultimately derives) and uses the associated component's Site property to obtain the service. This means we have to site MyControl with an ISite implementation.

For this purpose, you can create a stub implementation of ISite, and that's what I've done here with StubSite:

internal class StubSite : ISite
{
    private Dictionary<Type, object> services_;
 
    internal StubSite()
    {
        this.services_ = new Dictionary<Type, object>();
    }
 
    // ISite Members go here
 
    #region IServiceProvider Members
 
    public object GetService(Type serviceType)
    {
        if (this.services_.ContainsKey(serviceType))
        {
            return this.services_[serviceType];
        }
        return null;
    }
 
    #endregion
 
    internal void SetService(Type serviceType, object service)
    {
        this.services_[serviceType] = service;
    }
}

As you can see, I've omitted some members, but all of them just throws a NotImplementedException, since I don't need them for the test.

This stub site class can now be injected with services, which is what happens next: Stubs of IMenuCommandService and ISelectionService are injected into the stub site. These stubs are also implemented as internal classes in the test project, and are quite similar to StubSite in that they mostly ignore method calls or throw a NotImplementedException.

With all the services in place, we can now create the control and site it. The instantiated control is then used to initiatialize the designer, which retrieves the injected StubMenuCommandService and creates the designer verb.

The next steps just add some Button controls to MyControl and selects two of them (using the stub selection service).

At this point, we can loop through all the designer verbs of the designer and invoke the Reverse order verb if found. This should cause the sequence of child Buttons to altered, because the two selected Buttons should have been reversed so that button3 comes before button2.

Obviously, this test will currently throw a NotImplementedException when the Invoke method is called on the Verb, since that's the current implementation of the OnReverseOrderInvoked method in MyControlDesigner.

With a failing test, you are now ready to begin the test-driven development process of implementing the OnReverseOrderInvoked method to make the test succeed.

Some parting words: In a real-world scenario you'll need more tests to cover different aspects of the order reversing logic: The designer verb should only be enabled if two or more child controls are selected, maybe the verb should not be visible when other controls external to MyControl are selected, etc.