Running Unit Tests in Parallel

Its been possible to run unit tests in parallel for some time now, but it doesn't seem to have taken off. NUnit has had a parallel runner (PNUnit) since 2007, MsTest since 2009. I think running tests in parallel has two distinct benefits:

1. The test run will complete a little sooner.
2. It will help to test your system for concurrency issues.

HOWEVER, all your tests must be thread-safe. Writing unit tests that can be run in parallel can be difficult and designing and writing a system that allows parallel unit testing can be even harder. Statics and singletons will be the undoing.

So how do you set up tests to run in parallel?

For MsTest you will need to edit the .TestSettings file with a text editor (or right click in Visual Studio and open with Xml Editor).

Set the number to the number of cores you want to use for running tests. Setting this to a number greater than cores you have in your system will have no benefit. Setting it to 0 will auto-configure and use as many cores as the runner can. Remove the attribute completely to disable.

This will then ensure running the tests from within Visual Studio's Test menu run in parallel. (Make sure the testsettings file you modified is selected as the current active settings file, do this in the Test menu). If you're using Resharper I'm not certain it honour's all the settings in the testsettings file. (I didn't notice any difference with parallel enabled).

Setting it up for NUnit is a bit easier, it simply means you use a different runner. The bad news is that its command-line only with no integration into Visual Studio. See PNUnit for details on downloading the runner.

Optimised binary serialisation and serialisation tips

During some research a colleague of mine (thanks Richard)  has done into serialisation lately, two code project articles came to my attention.

Top Ten Caching mistakes, and
Optimizing Serialisation in .NET

The first one talks about some common mistakes and why they are mistakes and also some mitigation techniques.

The second talks about the problems using XML, DataContractSerialisation (or any text based serialisation for that matter).  Basically, they can be much slower than what you require. Also the binary serialisation and deserialisation process can create unnecessary data.  The article shows a custom binary serialiser that looks very useful.

Using IoC for Extensibility

MEF is probably a better choice if you know up front there is a good likelihood of consumers wanting to extend your application by injecting their own types.  However, I think there are a few exceptions to this rule.

Firstly, most modern software applications make extensive use of IoC to loosely couple dependencies and allow easy unit testing.  Also, sometimes you don't think it is likely someone will want to swap out a class, but don't want to rule it out either.  Building in MEF support for unlikely cases is a waste of time in my opinion, especially if there are ways to override behaviour using the IoC mechanisms you're already using. In these cases I prefer to allow consumers to override the IoC registered types.

I did a post some time ago on how to prevent IoC configuration chaos (refering to the explosion in size of your app.config if you put all registrations in it). This post discusses using code registrations and a mechanism to automatically run the registration code for each assembly on start-up.

This idea can be extended to allow custom extensions to be added.

By default Unity doesn't allow types to be registered that are not referenced by the application (I think Structure Map doesn't allow this either).

Scenario 1)
A consumer of an application that is already fully completed wants to change some behaviour in that application, and they do not have the source code, just the binaries. The application uses the IoC pattern referenced by the blog post above.
The consumer can create a new application project that references everything the original application and basically wraps around it. The new application includes any new  references required to new assemblies containing classes you want to use in IoC registration.  On start-up the new application simply delegates into the original. Now you can customise the IoC mappings in the App.Config of the new application. This works great for windows services, web services, console applications, and some UI applications. This is the preferable scenario.

Scenario 2)
Another option is to customise the IoC pattern described in the blog post mentioned above. When the initialisation process is looking referenced assemblies in the AppDomain, you can add some IO code to scan for assemblies in a folder.  These new assemblies can be loaded with reflection and added into the AppDomain. Once this initialisation process is complete the App.Config can be applied. This is less desirable because the author of the original application has little control over how customisation are used by the original system. Potentially a security risk.
You could modify the reflection assembly loading mechanism to only allow assemblies with a certain signing key for example to mitigate this security concern.

Type Visualiser version 1.08

Type Visualiser version 1.08

New features and changes:

• Thickness of the dependency line indicates how dependent the subject is on the dependency.
• Added 64 bit and 32 bit release mode executables.
• Allowed combined hide filters (ie combine hide-trivials with hide system types).
• Added support for saving diagrams and reloading them.
• Properly name generic types rather than simply List now will be List.
• Choose type dialog will now remember the last assembly opened.
• Added icons and count for trivial and non-trivial dependencies on the subject.