software.herbrandson.com

Dear WebForms,

I’m writing this to let you know that it’s over between us. I realize we’ve been together for some time now, but over the years things have gotten bad and it’s time to call it off. Don’t worry, it’s not you, it’s me. Well, actually that’s not true. It’s really you. You’ve really let yourself go over the years. But it’s not just about that. I’ve tried for years now, and the truth is I just don’t understand you. I feel like you’re always trying to hide what you’re really doing from me. You just keep too many secrets. How can we have a healthy relationship without total transparency? Also, you don’t seem to get along very well with some of my other close friends like JavaScript and TDD.

We have been together for quite a while so I feel like I owe you total honesty. The truth is I’ve been seeing someone else for the last few months. MVC and I have been spending more and more time together and it’s becoming obvious that we’re in love. I know you’re thinking this is about being traded in for someone younger and lighter weight, but it’s about a lot more than that. MVC just makes my life simple. It’s flexible and understanding when I need to do things in a different way it’s used to. It gets along really well with my other web dev friends. Most of all, I feel like I’m really on the same page as MVC. We think alike. MVC is up front, honest, and clear about what it’s up to. I don’t feel like it’s trying to hide things from me.

So that’s it. This is the end. Thanks for the memories. Don’t try to change my mind, I’m already gone.

~Me

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