Parameterized tests in NUnit

In an earlier post I showed how to pass parameters to test methods using an NUnit RowTest extension. As of version 2.5, the extensions are no longer packaged with the NUnit installer. The good news is that the addition of parameterized tests replaces the RowTest and adds a number of new features as well.

For reference, my previous RowTest looked like this:

[RowTest]

[Row(2, 3)]

[Row(-1, -4)]

public void AddTwoNumbers(int x, int y)

{

    Assert.AreEqual(x + y, Add(x, y),

        "Add returned incorrect result");

}

A basic switch to a parameterized test is a matter of dropping the RowTest attribute and replacing each Row attribute with a similarly-formatted TestCase attribute. The new code, which creates two distinct tests as before, looks like this:

[TestCase(2, 3)]

[TestCase(-1, -4)]

public void AddTwoNumbers(int x, int y)

{

    Assert.AreEqual(x + y, Add(x, y),

        "Add returned incorrect result");

}

In addition to single parameters you can now specify ranges. If I want to test values of X from 1 to 5, with a Y value of 1, I can do so using the Range and Values attributes, like so:

[Test]

public void AddTwoNumbers(

                    [Range(1, 5)]int x,

                    [Values(1)]int y)

{

    Assert.AreEqual(x + y, Add(x, y),

        "Add returned incorrect result");

}        

In the test runner, this shows up as five distinct unit tests


If I specify the range 1-5 for both X and Y, NUnit defaults to creating 25 unique tests. This is the default Combinatorial attribute.


If I wish to use a value from each range only once, I instead mark the test as Sequential

[Test, Sequential]

public void AddTwoNumbers(

                    [Range(1, 5)]int x,

                    [Range(1, 5)]int y)

{

    Assert.AreEqual(x + y, Add(x, y),

        "Add returned incorrect result");

}        

which produces the desired effect

Save WinForm control values between executions

Say I have a test application that submits info to a webservice. Because this webservice has a few issues, I may need to retry a request several times to get a valid response. I've added a control to set the number of retries.


Specifying the control's Value property at design-time sets the starting value at runtime. If a user wants to set a different value, he must do so each time he starts the app. To make things more user-friendly it would be better to save the control's value between executions.

To do so, start by selecting the desired control in the designer. In the Properties window, expand the ApplicationSettings entry and select the ellipsis (...) for the PropertyBinding sub-entry.


In the Application Settings dialog that appears, select the dropdown next to the 'Value' entry, as this is the property we wish to persist.


Select the '(New...)' link from the popup, which brings up the New Application Setting dialog.


Specify the default value and name of the config setting (and modify the Scope if necessary) and press OK. This will update the Application Settings dialog to show the newly added entry.


Press OK to close the dialog. With the property binding set, the application will automatically load the value at startup. The only thing left is to save the modified value. In the form's FormClosing event handler, add the following line:

Properties.Settings.Default.Save();

At this point the change is ready to test. Start the application and modify the control's value. Without doing anything else, close the application. Now restart the app. Note the control contains the modified value.

It would seem the desired functionality is complete but there is one more item that needs to address. If you look for the saved settings file, you will find it under

C:\Documents and Settings\<username>\Local Settings\Application Data\<Company>\<AppName>\<version>

If the version number for the application is changed, the previously saved setting won't be loaded. The application needs to know to upgrade the saved settings the first time it runs.

Start by adding a new application setting called UpgradeSettings. This will be used to make sure we only upgrade the settings once. Otherwise, any newly saved settings will be replaced by the previous version's settings every time the app starts.


The final step is to add the upgrade logic to Program.cs. In the Main method, add the following code immediately before the call to Application.Run.

if (Convert.ToBoolean(Properties.Settings.Default["UpgradeSettings"]))

{

    Properties.Settings.Default.Upgrade();

    Properties.Settings.Default["UpgradeSettings"] = false;

}

No-hassle SQL connection strings

Most applications working with a database handle the connection string in one of two ways: Hard-coding the full string or doing some amount of string concatenation. A typical concatenation method looks something like this:

public string OldMethod(string server, string database,

                        string username, string password)

{

    string connectionString = "Data Source=" + server + ";";

    connectionString += "Initial Catalog=" + database + ";";

    connectionString += "User ID=" + username + ";";

    connectionString += "Password=" + password;

    return connectionString;

}

I admit this is fairly simple code. The only potential issues might be a property name typo or a misplaced (or missing) semicolon. But why hassle with even that much when the dotNet Framework has the same functionality built into the SqlConnectionStringBuilder class? With a reference to System.Data.SqlClient, the above method can be replaced with:

public string NewMethod(string server, string database,

                        string username, string password)

{

    SqlConnectionStringBuilder connBuilder 

        = new SqlConnectionStringBuilder();

    connBuilder.UserID = username;

    connBuilder.Password = password;

    connBuilder.InitialCatalog = database;

    connBuilder.DataSource = server;

    return connBuilder.ToString();

}

In either case, the output is identical:

Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword

Note: If you are working with a database other than MSSQL, there are several other classes derived from the common DbConnectionStringBuilder base class, such as OdbcConnectionStringBuilder and OracleConnectionStringBuilder.

Quickly escape strings in xml

If you spend much time working with xml, you will find yourself needing to escape strings. Replacing '<' with '&lt;' for example. Usually the code written to do so looks something like this:

escapedItem = itemToEscape.Replace("&", "&")

                          .Replace("<", "&lt;")

                          .Replace(">", ">")

                          .Replace("'", "'")

                          .Replace("\"", """);

Though this technically works, there is an easier way built right in to the .Net framework. If we reference System.Security we can replace the above code with

escapedItem = SecurityElement.Escape(itemToEscape);

In both cases, the string

If (x < 2) & (y > 3), where \"x\" isn't...

is replaced with

If (x < 2) & (y > 3), where "x" isn't...

An easier way to manage CruiseControl.Net projects

In a much older post I showed a quick way to remove duplication in a CruiseControl.Net (CCNet) config file. Since then, CCNet has added a Configuration Preprocessor to not only simplify this process, but also split the ccnet.config into multiple files - one per project.

To start with, we need to modify ccnet.config to specify the correct xml namespace:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">

Now we move an existing project from ccnet.config into a separate file. Note this new file starts with 'project' as the root node, and must also have the correct xml namespace.

<project xmlns:cb="urn:ccnet.config.builder">

    <name>My Test Project</name>

    <triggers>

        <intervalTrigger seconds="60" />

    </triggers>

    <sourcecontrol type="svn">

        <executable>svn.exe</executable>

        <trunkUrl>svn://MySourceServer/myAppPath</trunkUrl>

        <workingDirectory>C:\CCNetProjects\MyTestProject</workingDirectory>

        <username>svnUser</username>

        <password>svnPassword</password>

        <autoGetSource>true</autoGetSource>

    </sourcecontrol>

    <tasks>

        <msbuild>

            <logger>c:\ThoughtWorks.CruiseControl.MSBuild.dll</logger>

            <projectFile>MyTestProject.sln</projectFile>

            <buildArgs>/noconsolelogger</buildArgs>

            <targets>Build</targets>

            <workingDirectory>D:\CCNetProjects\MyTestProject</workingDirectory>

        </msbuild>

    </tasks>

    <publishers>

        <statistics/>

        <xmllogger/>

        <artifactcleanup cleanUpMethod="KeepLastXBuilds" cleanUpValue="25" />

    </publishers>

</project>

In the main ccnet.config, our project information can be replaced with an include that points to our new project config:

<cb:include href="C:\MyTestApp.ccnet.config" />

Instead of one massive config file, we now split it by project. This makes adding, removing, or modifying projects much easier. As an added bonus, CCNet monitors the project-specific config files and reloads them if anything changes.

I mentioned that we can also use the preprocessor to reduce duplication. In the project config above, note the Subversion username and password nodes:

<username>svnUser</username>

<password>svnPassword</password>

If we define these values in each individual config, changing them requires a find/replace across multiple files. What we want to do is define them once in the main ccnet.config and then include them in our project configs. To do this, we start by adding the following to ccnet.config

<cb:define name="svnCredentials">

    <username>svnUser</username>

    <password>svnPasswrod</password>

</cb:define>

In our project config we can replace the two credential nodes with a single reference to 'svnCredentials'. If we ever change the account our buildserver uses to pull code, we only need to change the credentials once.

<sourcecontrol type="svn">

    <executable>svn.exe</executable>

    <trunkUrl>svn://MySourceServer/myAppPath</trunkUrl>

    <workingDirectory>C:\CCNetProjects\MyTestProject</workingDirectory>

    <cb:svnCredentials/>

    <autoGetSource>true</autoGetSource>

</sourcecontrol>

Mmc load failure

After running our legacy installer we ran into yet another problem - the Computer Management administrative app quit working. Attempting to start it gave an error stating:

MMC cannot open the file C:\WINDOWS\system32\compmgmt.msc.

This may be because the file does not exist, is not an MMC console, or was created by a later version of MMC. This may also be because you do not have sufficient access rights to the file.

To debug this particular issue, we turn to Process Monitor. When we start up the app, the first item shown is a filter dialog. For this session, we need to add mmc.exe to the list of processes to monitor.


Though it's useful to see all activity for a given process, we are generally focused on errors. To make this easier, we want to highlight any log entries that do not have a Result of 'SUCCESS'


Once we have Process Monitor configured and running, we can start the Computer Management tool. The logs will quickly fill up with registry and filesystem events, many of which will be highlighted


In the above screenshot, notice the registry ReadOpenKey failures for various items under "HKCR\CLSID\{2933BF90-7B36-11d2-B20E-00C04F983E60}". I don't know off hand what those sub-items specify, but without them I do know you will be unable to load the associated COM object. To determine what dll was at fault, we went to another computer and looked for that section in the registry.


Note above the default value of "C:\WINDOWS\system32\msxml3.dll." For whatever reason, our installer was unregistering this system dll - definitely not a good thing. Fixing the problem on the broken box was as simple as running regsvr32 on msxml3.dll.

Runtime profiling a COM registration failure

As a continuation of my last post, we had another registration error with the same legacy installer. This time the problem was with mssoap30.dll. Loading the dll in Dependency Walker revealed a single error with dwmapi.dll.


With a bit of web searching we found that dwmapi.dll is only present on Vista and later machines. Since we weren't using that dll directly it shouldn't be the cause of our issue on Windows XP.

At this point it would appear we have all necessary dlls and that our problem must be elsewhere. The documentation on Dependency Walker, however, provides some useful information:

When a module is first opened by Dependency Walker, it is immediately scanned for all implicit, delay-load, and forwarded dependencies. Once all the modules have been scanned, the results are displayed. In addition to these known dependencies, modules are free to load other modules at run-time without any prior warning to the operating system. These types of dependencies are known as dynamic or explicit dependencies. There is really no way to detect dynamic dependencies without actually running the application and watching it to see what modules it loads at run-time.

Version 2.0 and later of Dependency Walker provides a Profile option from the menu. If you have a dll loaded, however, the item is disabled - you have to load an executable first.


For this to work, you need to load regsvr32.exe, which will enable the menu items. Once done, select Profile > Start Profiling to bring up the Profile Module dialog. The only necessary change is to add the dll being registered to the "Program arguments" setting.


Press OK and wait for the application to run. Eventually you will see the usual registration error message box, which you can simply click to continue. Once finished, scrolling through the results shows a couple errors for mssoapr3.dll.


The first error states that the file path specified can't be found. Double-clicking the error shows that it is looking for the dll under "c:\temp\1033". The second states that it cannot find the file - this time in the same folder as the dll we tried to register. So it seems either location is valid for this particular dependency.

Once we add mssoapr3.dll to the same folder, mssoap30.dll registers without issue.