Inspired by Roy and Andrew, I have been itching to try using MbUnit on a new project. This evening I got a chance to do that. I have a tool I use for several projects, and I wanted to add a bunch of features to it, so I seized the day.

It's been at least a year since I used MbUnit for a real project. In that time, my unit testing style has changed a lot.

I'd say the biggest change for me came after watching Brad Wilson write unit tests in front of an audience at Seattle Code Camp last year (link broken at time of writing). The speed and rhythm he had going really left an impression, and changed my style. It caused a bunch of things to gel for me. Watching a pro do Unit Testing is a great thing. (Also check out John-Paul Boodhoo in the DNR TV Videos he and Carl made.)

Since then, I often write a method, and maybe the first thing I want to do is write a guard clause. I write a test to feed in the base value, then write the guard clause. I might have a series of bad scenarios, then finally, the normal flow, which is often my last unit test before deciding I am done (for now.)

So I end up with unit tests that look like this (maybe with ExpectedExceptions, but usually just verifying a return value or something):

[Test,ExpectedException] public void EdgeCase() {}

[Test,ExpectedException] public void EdgeCase() {}

[Test,ExpectedException] public void EdgeCase() {}

[Test] public void MainFlow() {}

Everything is very explicit, with a "statement" for every part of the contract the method implements...kind of like a verbose legal contract.

So the first thing I notice writing tests like this in mbunit is that these collapse down to:

[RowTest, ExpectedException, Row, Row, Row, ...] public void EdgeCase() {}

[RowTest, Row, Row, Row, ...] public void MainFlow() {}

It's about 30% faster for me to write the RowTest version, even though I have a CodeRush template for simple unit tests and expected exception tests. RowTests are just plain more concise. More like notesy instructions to your coding buddy than formal legal contract.

The only thing I don't like about this is the way the code looks formatted. Readability is very big for me, and I like collapsing my tests up so they look this this:

[Test] public void SomeMethod_ShouldDoSomething() ...

[Test] public void SomeMethod_ShouldDoSomethingElse()...

[Test] public void SomeMethod_ShouldntDoSomethingBad()...

All the Rows end up pushing the method name out of the right margin, or force me to put in line breaks.

But that's just being nitpicky. I'm sure I'll figure something out.

Currently listening to Party For Your Right To Fight by Public Enemy from the album It Takes A Nation Of Millions To Hold Us Back