Something I am a really big fan of is Unit Testing.  I was a big evangelist of unit testing at my last company.  The code my team wrote unit tests for was, on average, much better code than code that was written without unit testing.  Code-testing coverage via unit testing creates solid code.  It allows developers to thoroughly test their code in an automated fashion.  Unit tests give the developer confidence that they have introduced few or no regressions with new functionality added to old code.  All one needs to do is re-run the old unit tests to ensure everything still works.  Unit tests are a great form of documentation.  When a developer maintains code written by another they can inspect unit tests to see how the code is used, and can run these unit tests to ensure they aren’t breaking functionality they may not understand.  Ultimately unit tests act like a code specification.  In fact there is a style of coding called Test Driven Development (or its sexy new name, Behavior Drive Developer) that mandates that the tests be written first, and then the code is not considered complete until it satisfies the tests.  And even when unit testing is not take to that extreme, developing code that works well with unit tests usually ensures well-designed code from an object-oriented standpoint.  Code that is easily tested by a unit test is usually adequately decoupled and uses OO principles like inheritance, encapsulation and polymorphism in the right way.  Finally, writing code with unit tests can be faster.  Running tests can take less time than standing up an application and entering in the correct criteria to test the code in question.

At my current employer I have found myself working with a very mature (and very good) code-base that does not lend itself to unit testing.  It has probably been a year since I have written a unit test at work.  So when I started diving back into Silverlight I made it a goal to write our new framework to be as compatible with unit testing as possible.  This will help lesson the burden on our QA team, which has already written a lot of UI testing for our current ASP.Net web application.  We will also receive all the benefits mentioned above.

To start off I needed a unit testing framework.  NUnit is my old unit-testing friend and was my first thought.  However, NUnit and other unit testing frameworks don’t work in Silverlight-land, since Silverlight relies on a slightly different set of core .Net assemblies.  I did discover that there is a Silverlight version of NUnit and I considered it.  I also found the Silverlight Unit Testing Framework from Microsoft thanks to a post over on Scott Gu’s website.  The Silverlight Unit Testing Framework is based on the Microsoft library for normal .Net (which is also based on NUnit) but runs in Silverlight, in the browser.

Ultimately I chose the Microsoft library for a couple of important reasons.  First, there seems to be more acceptance and more example of the Microsoft library.  Second, the Silverlight Unit Testing Framework does one thing that is very unique compared to other unit testing frameworks: it runs the tests in the UI thread.  Jeff Wilcox, one of the authors of the framework, has an excellent post here about why Microsoft chose to do this, and it really makes sense.  Silverlight is a graphical library, and bugs will best be found if testing is written from a user-interaction standpoint.  Many things run on the UI thread, or are marshaled back and forth.  The Microsoft Silverlight Unit Testing Framework can work both as a unit testing framework and as a kind of integration testing framework.  The framework makes it very easy to test off the UI thread, and test asynchronously.  I found this excellent post on using the async features of the Silverlight Unit Testing Framework.  It really boils down to the testing environment being the same as the real run-time.  I have run across enough idiosyncrasies in the way Silverlight handles UI thread interaction to know that testing without it will miss a lot of bugs.

I have developed some “test” tests on business objects.  I also tested a thread manager I wrote using the built-in async functionality.  With the experience so far, I feel happy with the results.  My next step is to look at pluging in the unit tests into the automated build at work…