May 182011
 

When doing TDD or at least unit testing, it is necessary to know how much of your code is covered by tests and, more importantly, which code isn’t. Since we migrated to NUnit the integrated Visual Studio 2010 code coverage does not do the job anymore for us (although I’ve found several articles on how to enable it, for some reason I couldn’t get it running).

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.

Continue reading »

May 182011
 

 

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.

Continue reading »

May 182011
 

 

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.

Continue reading »

May 172011
 

 

I often work on various branches of the same project (using TFS). This means that I have folders setup like:

[root]/Project

[root]/Branch A/Project

[root]/Branch X/Project

Sometimes I have to keep multiple Visual Studio instances open at the same time with branches of the same project and because by default VS2010 only displays the solution name in the title bar, switching between different windows can become very confusing.

Continue reading »