I was recently reminded of this by Scott Bellware on this hanselminutes episode.

It’s easy to fall into the trap of thinking about TDD as a testing technique.  I mean, Test is the first word in TDD.  And normally you hear it talked about as Test Driven Development, not Test Driven Design.  Since most development going on is probably not Greenfield, but is in maintenance/support mode, I’d bet that those involved with most applications think that the design phase is “done”.  Even when new features are being added to an existing application/platform, it’s not like you’re starting from scratch, you’re usually bolting things on to existing functionality.

And therein lies a pitfall.  Most people would probably be more concerned with not breaking existing functionality, as opposed to letting TDD help design the new functionality.

Another pitfall comes from that first word, Test.  Don’t get me wrong, I love tests.  However, it is quite possible that you follow the red/green/refactor methodology of writing tests and still come out with poorly designed code. This comes from what I like to call the “Mother of Invention Principle”.  Yeah, I just coined a principle.  Basically, one of the ideas of TDD is that there should be no new code added until it is required by at least one test.  So, if you follow this principle, then you should technically have 100% code coverage when finished.

Unfortunately, 100% code coverage isn’t useful.  Anything but 100% would be useful (but more on that in another post.)  Maybe the tests were poorly designed.  Maybe the tests are spot on, but they require huge amounts of setup and teardown for each test.  Sure, it’s tested, but is it designed well?

This kind of thinking, about “fully” tested code, sure make TDD a good sell to management and QA, but alas, that’s not what TDD was meant for.

Anyway, I won’t belabor the point, listen to the podcast.  Scott and Scott talk about this much more eloquently than I can.

I’ve don’t like writing unit tests, plain and simple.  Do I write test code?  Absolutely.  I think not writing tests will set you up for a truckload of fail.

What I don’t like about writing the tests is the seemingly foreign language that their written in.  Sure it might be C# or VB, but it looks drastically different from the object oriented code we write on a daily basis.

   1: MyClass superGuy = new MyClass();

   2: string result = superGuy.GetResult();

   3:

   4: Assert.AreEqual("good result", result);

I just don’t think that way.  For one, I can’t just look at that line and know what’s being tested without having to read through the entire line, Two, it takes me a few seconds to mentally adjust to thinking about the code that way.  Finally, I have a tendency to swap the expected and actual when writing out the asserts which confuses me when the assertion fails.

Wouldn’t it be nice to be able to write:

   1: MyClass superGuy = new MyClass();

   2: string result = superGuy.GetResult();

   3:

   4: result.IsNotNull();

   5: result.IsEqualTo("good result");

   6: // or combine them

   7: result.IsNotNull().And.IsEqualTo("good result");

That’s what spectacle is all about.  It’s a collection of extension methods to ease the pain when writing unit tests.  It only targets MbUnit v2 right now, because that’s what I’m currently using.

If you want to try it out, clone it from the github repository and build it.  Next all you’ll need to do is add a reference to your test project  and add a “using Spectacle.MbUnitAssertions;” to your code files.