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.

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

Shout it