Changing the project type is an easy task. You need to open up the .csproj file in a text editor and add the following tag under the <PropertyGroup> element:

<ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

You will also need to add the following WPF references with Visual Studio:

• PresentationCore
• PresentationFramework
• System.Xaml
• WindowsBase

Once everything is done, you can add a new CustomControl to the project:

You can get more information about how Unity works and also download the latest release from Codeplex: http://unity.codeplex.com/

The problem with Unity is that you have to have all dependencies registered in the container, otherwise when you will try to resolve a type that depends on other non-registered types you will get an exception. Other containers like StructureMap (http://structuremap.net/structuremap/index.html) have a method of validating the entire configuration so that you can use it in an automated test.

Since Unity lacks this functionality, I have decided to create an extension method that will validate all mappings. Basically this method goes through all registered types and tries to resolve them. If a type is not properly registered, it will fail and the exception you get from Unity lets you know which mapping is invalid.

You can get the code for the extension here: http://codepaste.net/hqf45s

I have created a reusable class that accomplishes this task. The class uses a timer internally and defers the execution until the timer interval elapses. If the event fires during the timer interval, the timer interval is reset. The current implementation uses a DispatcherTimer to execute the event (because I use it in UI-related code), but can be easily changed to use another timer if you need it.

Using the LazyAction class is straightforward. You need to declare a field of type LazyAction:

 1: private readonly LazyAction lazyAction;

Somewhere (probably in the constructor) you need to initialize it:

 1: public MyClass()

 2: {                 this.lazyAction = new LazyAction(TimeSpan.FromMilliseconds(10), DoSomething);

 3: }

The constructor of the lazy action has two parameters:

• deferredUpdateDelay – the time interval from the last call to Execute after which the action really gets executed
• action – the action to execute

Suppose you handle the MouseMove event inside your class, you would execute the lazy action like this:

 1: private void canvas_MouseMove(object sender, MouseEventArgs e)

 2: {     this.lazyAction.Execute();

 3: }

There is just one caveat in using this approach – unit testing (at least using MSUnit) does not work as expected. The reason is that by using the DispatcherTimer inside our class, the timer won’t fire when running unit tests. This is caused by the fact that during running the unit tests the Dispatcher doesn’t automatically process its queue. A workaround for this is using the DispatcherUtil class found in this StackOverflow discussion: http://stackoverflow.com/questions/1106881/using-the-wpf-dispatcher-in-unit-tests 

Get the code here: LazyAction.zip

The great thing is that you can look at bindings, change properties at runtime and instantly see the changes, monitor events and also put breakpoints on property changes.

You can find download this from CodePlex: http://snoopwpf.codeplex.com/ 

Also, you can follow Cory Plott’s blog here for more updates, tips and tricks: http://www.cplotts.com/

I would really like more suggestions about cool extensions that you are using in your development process.

There are two tools that you can use instead – one of them is NCover, which is a great tool but not free. The other one is PartCover, which is a free code coverage tool. I’ve opted to go with the latter. The main problem with PartCover is the almost non-existent documentation. After several hours of trying out different combinations of options I finally got it running and it does it job really good.

So first of all, download PartCover from here: https://github.com/sawilde/partcover.net4 and install it. Then, we must configure it for running our tests. Before we do this, we have to do one small step (which btw was the hardest one to find out) to make our nunit-console runner successfully run .NET 4.0 projects.

Open up Windows Explorer and go to your nunit installation directory (in my case it’s C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0). Open up nunit-console-x86.exe.config and add the following tag at the beginning, right after the <configuration> tag is opened:

<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
This will make the nunit console run .NET 4.0 projects. You can do the same for all other nunit config files.

Once you’re done, open the PartCover browser and go to File->Run Target…

In the Executable file box, browse for the net-2.0\nunit-console-x86.exe file. This should also set the working directory automatically.

In the working arguments enter the following text (replace the solution name and path with your own, but leave the double quotes): /noshadow "C:\My Projects\MyProject\MyProject.sln"

In the rules box, you need to add rules to include all assemblies that you want to check for code coverage and to exclude unnecessary assemblies. I use something like:

+[*MyProject*]*

-[*Test*]*

This will include all assemblies and namespaces that contiain “MyProject” in their name, but will exclude all assemblies and namespaces that contain unit tests.

Don’t forget to save the configuration for further use.

Then press start. It will run the console and show you a tree with the code and its coverage.

One of our main requirements when performing the migration was to have the same level of integration with our Team Build system. This means that the build should run all tests and fail if any test fails. Also we should be able to see in the build log which tests have failed.

This step is the most complicated one so here is a quick breakdown of all the steps involved:

1. Setting up the build server
2. Changing the build template
3. Add a new ForEach sequence to iterate through all test assemblies
4. Add a sequence to run all tests in a single test assembly
5. Invoke NUnit
6. Publish NUnit results
7. Mark the build as broken if not all tests pass
8. Modify the workflow to support projects without a test settings file
9. Check in the build template file.

Setting up the build server

The first step is to setup the build server. I have created a folder called C:\tfstools with two subdirectories: NUnit and NUnitTfs.

The NUnit folder contains the latest release of NUnit (just the binaries, no installer) and the NUnitTfs folder contains the latest release of NUnitTFS (http://nunit4teambuild.codeplex.com/releases/view/45765). After placing the files in there, make sure that the configuration file for NUnitTFS has the correct server address in each service endpoint.

There are no other configuration steps to be done on the build machine. The following steps must be done for each TFS project that uses NUnit:

Changing the build template

The process to setup this step was mainly inspired by this blog post (http://www.heikura.info/blog/publish-nunit-test-results-as-part-of-team-build-in-team-foundation-server-2010). Unfortunately, by following only the steps there I wasn’t able to setup everything correctly (that post also doesn’t go into how to run all test projects during a build), so after a lot of trial-and-error I finally managed to get the whole process running:

In the Team Explorer window open the source control entry for the project in which you want to enable NUnit support. Open the BuildProcessTemplate folder and check out the DefaultTemplate.xaml file.

Setup build arguments

Open the DefaultTemplate file and on the bottom click the Arguments button. In the grid that shows up add two entries as in the following screenshot:

• NUnitBinaryDirectory – [In], String, “C:\tfstools\NUnit\bin\net-2.0”
• NUnitTfsPublisherDirectory [In], String, “C:\tfstools\NUnitTfs”

Add a new foreach sequence to iterate through all test assemblies

Locate the sequence with the title “If testAssembly.HasTeestSettingsFile” (should be around half-way down on the whole flow).

In the “true” branch of the if statement you should have these two actions:

Insert a ForEach<string>action above them and change the properties as follows:

Add a sequence to run a set of tests

Inside the body of the foreach, add a sequence that will hold all following steps. Change the DisplayName property to “Run NUnit tests”. Select the new sequence and open the variables grid. Add a new variable called NUnitResult, Int32. The scope should be “Run NUnit tests”:

Add the Invoke NUnit action

In the newly created sequence add an InvokeProcess action, and inside the new action add a WriteBuildMessage and a WriteBuildError action like in the following screenshots.

The properties for the WriteBuildMessage and WriteBuildError should look like this:

Add the publish NUnit results action

After the Invoke NUnit action (in the same sequence) add a new Invoke process action. Call it “Publish NUnitTests” and copy paste the inner WriteBuildMessage and WriteBuildError actions from the “Invoke NUnit” action created at the previous step.

Set the Arguments to:

Set the FileName to:

And finally, set the WorkingDirectory to outputDirectory.

Add an if statement that will set the test status to error if the tests don’t pass

At the end of the same sequence add an If statement. Set the condition to NUnitResult <> 0 and in the “Then” branch add an assign action. Set the properties as follows:

The if action should look like this in the end:

Done

If you have followed all the above steps, you should get a sequence as in the following screenshot:

Wait, there’s more

The above steps ensure that the Team Build server will run your NUnit tests when you have a test settings file. You have to do one more step (I promise it’s an easy one ) to get the tests to run also when you don’t have that file.

Scroll a bit above to the “If testAssembly.HasTestSettingsFile” action. Cut the “Run MSTest for Test Assemblies” action from the “Else” branch and replace it with a Sequence. Paste back the action inside the sequence. Then, Copy the “Run all NUnit tests” action from the “Then” branch and paste it above the “Run MSTest for Test Assemblies action”:

The final result of the “Else” branch should look like the screenshot above.

The end (for real now)

Check in the DefaultTemplate.xaml file and you’re done. When you build your project now it should run all NUnit tests as part of the build process.

Check out the next parts of this series here:

• Code coverage

Fortunately, this is really a very simple step (or at least in our case it was):

1. Remove the reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework and replace it with a reference to nunit.framework. If you use nuget, you can add a library reference to the NUnit package.
2. You need to do some search & replace in all files. The table below illustrates what to search for and what to replace it with:
   

   Search (MSUnit code)	Replace with (NUnit code)
   using Microsoft.VisualStudio.TestTools.UnitTesting;	using NUnit.Framework;
   [TestClass]	[TestFixture]
   [TestMethod]	[Test]
   [TestInitialize]	[SetUp]
   [TestCleanup]	[TearDown]
   [ClassInitialize]	[TestFixtureSetUp]
   [ClassCleanup]	[TestFixtureTearDown]

3. At this step you should be almost done. One of the issues I had with the code is that I used in several places the Assert.IsInstanceOfType assertion. It seems that the NUnit assertion expects arguments in the opposite order than MSUnit. Also there is a generic Assert.IsInstanceOf<> method that you can use. I’ve made a search and replace regex that will fix most of these assertions in your code:

   For convenience, the search expression is: Assert\.IsInstanceOfType\({[^,:b]+}:b*,:b*typeof\({:i}\)\);
   and the replace expression is: Assert.IsInstanceOf<\2>(\1);

   Also, make sure you have the two checkboxes checked.

4. We also had some other errors in the tests, that required running the tests in a Single Threaded Apartment (STA) thread. To accomplish this, you need to decorate the test or the test method with the [RequiresSTA] attribute (check this link for more details: http://www.nunit.org/index.php?p=requiresSTA&r=2.5)

At this stage you should be done with the migration of the test code. If there are any other issues you encounter, please let me know and I will update this blog post with the steps involved.

Check out the next parts of this series here:

• Integration with TFS builds
• Code coverage

Since we are not using MSBuild anymore, we need some tools to help us in the testing process. Below are the tools that I currently use for this:

• NUnit GUI & Console runner (included in the NUnit setup) http://www.nunit.org/index.php?p=download
• Visual NUnit – for running and debugging tests inside Visual Studio 2010 http://www.bubblecloud.org/visualnunit (if you have a productivity tool installed, such as Telerik JustCode or JetBrains Resharper, you can use that to run tests)
• PartCover – for test coverage (will detail setting up this tool in a later blog post)
• NUnitForVS – one side effect of migrating existing Visual Studio test projects to NUnit was that we are able to use the integrated Visual Studio test runner. The only issue we’ve encountered is that running NUnit tests in this way is extremely slow (maybe some configuration issue?); you can check out this blog for more information http://bloggingabout.net/blogs/vagif/archive/2010/03/06/nunitforvs-integrating-nunit-tests-into-visual-studio.aspx

The NUnit GUI & console test runner come in two flavors – AnyCPU and x86. In my project I could only run the tests using the x86 runners (I have mixed projects – some using the x86 configuration, while most are built using  the Any CPU configuration).

Check out the next parts of this series here:

• Migrating test code
• Integration with TFS builds
• Code coverage

I am working in a large WPF project that is in a continuous evolution. Initially when we started the project we didn’t have any kind of unit testing in mind, then later we switched to an (almost) TDD approach. Since we use TFS for source control and automated builds, the natural decision was to use MSUnit as the test framework. Although this approach has some benefits, after the project has grown in size we have reached several limitations.

Just to name a few (disclaimer: I don’t want to turn this post in a flame war between MSUnit vs NUnit – I always think that you have to use the right tool for the right job):

• the integrated test runner is slow… too slow to be able to do TDD in a reasonable timely fashion
• lack of support for test input parameters (I know you can use databases to specify input parameters, but I find that setting up a database just to test 5 parameter combinations is a way too big overhead)
• the limited (and naïve) support for test inheritance

I find the last point to be one of the most problematic limitations on large scale projects that use inheritance extensively. We’ve found several workarounds, none of which make your life easier – from duplicating similar test code to making a base class (which must be testable by itself – which increases the complexity of the tests significantly) to using T4 templates for generating similar tests. None of this approaches are really good solutions since they all increase the maintenance time and the complexity and footprint of the test code.

So in the end, after several discussions, we have decided to try to switch from MSUnit to NUnit. This blog is the first one in a series that covers this transition touching all important aspects of such a transition:

1. Tools
2. Migrating test code
3. Integration with TFS builds
4. Code coverage