2008-05-04

MbUnit: Syntax Sugar for the Test-Driven Developer

I'm not going to profess to be the utlimate TDD guru; but I'm a firm believer and have been trying to continuosly better my skills in this development methodology.

I started my TDD experience about three years ago using CSUnit; but whas quickly moved to NUnit when we found that CSUnit wasn't totally meeting our needs. I've been with NUnit ever since and have heavily used it over the past year in NUnit GUI, NCover and MSBuild. It's easy to use and gets the job done well. The Unit Runner is a little lacking in some areas (mostly aesthetics... but we're not going for prize winning eye-candy... we're testing our code...) but it's functional and easy-to-use.

A friend of mine that works for LanDesk clued me in to one I hadn't heard before called MbUnit. I started searching around and realized that a lot of big names in the community seem to be excited about it. One blog post that really caught my eye and piqued my interest in checking it out was byScott Hanselman, entitled: 'MbUnit - Unit Testing on Crack'.

How wonderful it looked to write one short test for multiple scenarios rather than multiple test methods with basically the same repeated code over and over again with different test data.

So I took the simple phone number example I like to use when introducing someone to test-driven development and I made it my first experiment with MbUnit.

Without going into TOO much detail, I basically will have my phone number scenario be where we're going to write a utility class with a static method on it that will take a phone number string (in this case USA phone numbers) and return a boolean specifying its validity as a USA phone number format.

I make it a "red-green-refactor" scenario by first writing tests and implementing code that has pretty hard defined logic like string length tests, etc and then once I get some basic tests passing, I refactor the method's code to a regular expression and ensure the tests still pass. It's a fun little scenario and easy to help people pick up on the concept of Test-Driven Development.

In this scenario, the requirements were that the phone number had to be 10 digits and could only follow the formats (# representing a digit):#############-###-#######.###.####(###) ###-####

Anyway, I was very pleased with the Test Fixture and Test code and how nicely the Icarus test runner still views them as separate tests.

How cool is that to have your test method take parameters so the same test code can be used for multiple scenarios? Booya!

And you can see that I could easily add tests for non-USA phone number types by adding Row attributes that used a different value of the PhoneNumberType enum.

And here's how it looks inside Icarus:

Notice how it also shows the parameters being sent in to each test... makes it VERY easy to see what's going on with your tests. I love it!

Oh yes, MbUnit is Test-Driven Development evolved. I'm very excited about the potential of this framework.

Icarus Test Unit Runner is VERY alpha right now, but I'm excited at its potential. It's prettier than NUnit's GUI, though still showing its infancy. Icarus is very functional for being in alpha. Rumor is that ReSharper can also run MbUnit tests; so that will be awesome if that's true as well.

So, if you're a test-driven developer and you're looking for some new hotness in test-driven technology... I'd highly recommend looking into MbUnit.