software.herbrandson.com

I’ve recently been working on a project using Silverlight, and while there are many things I really like about Silverlight (like threads in the browser, heck yeah!) one thing that has been killing me is the Silverlight Unit Testing framework. It is painfully slooooooooooow. I currently have somewhere around 160 tests and it’s been taking over 30 seconds to run the suite. That fact, combined with the fact that there isn’t a way to run only one test was actually becoming fairly detrimental. I was finding myself skipping some simple tests just because it didn’t feel worth the wait. Or, I would write and implement multiple tests before running them, just to not lose my train of thought.

So the other day I thought I’d take a crack at building my own unit testing framework. It turned out to be really simple and after a few hours I had something up and running. The best part was that I could now run my 160 unit tests in under 2 seconds. Not too bad if I do say so myself.

Now, to be fair, the Silverlight Unit Testing framework does a lot of things that my little testing framework does not do. Most notably, my framework does not support testing UI elements. However, for my project UI testing is not what I’m most worried about. Hopefully there are others out there who are in a similar situation that will find this helpful.

But wait, there’s more! After doing TDD for a while now, one thing that can be annoying is when a test fails and you get a message like “expected:3 actual:7”. What expected 3? I wrote that test 4 days ago. I don’t remember what was supposed to be “3”. Typically, this problem is solved by adding a “message” to your Assert that might say something like “User.Age should equal 3”, but that requires extra typing and who has time for that? So now that I’d created my own testing framework I thought I’d try out a little experiment using lambdas. Why lambdas? Because there shinny and new. No, because lambdas can actually be used as an expression tree. That means that in addition to being able to execute the lambda, I can parse it out and turn it back into something that fairly closely resembles the original source code. It’s probably easiest to explain with some screen shots. Here are two tests that test the same thing. The first is using the traditional Assert.AreEqual syntax. The second one is using the new and improved lambda syntax.

And here are the test results for both of these failing tests. Notice that the first failing test result (the one using the lambda) gives you a lot more detail about what code actually failed. There’s no need for me to dig into the source code to find out what “expected 3 but was 7” means. Even better I still got to be lazy and didn’t have to type a descriptive message into my Assert.

If you’d like to try it out, I’ve tried to make it as easy as possible. I’ve created some “compatibility” namespaces in order to make it easier to switch frameworks (i.e. all the namespaces/class names/method names for my testing framework match those of the Microsoft one). For many scenarios it should be as easy as removing the reference to the Microsoft Silverlight unit testing framework from your test project and replacing it with a reference to this framework. I haven’t recreated everything from the Microsoft framework, but I think all of the essentials are there. Hopefully this will allow you to quickly assess whether this is a good solution for you or not. Any feedback would be great!

Source