We’ve all done it. You start a proof-of-concept project to try to figure something out. Almost no planning or thought goes into it, you just dive right in. You finally get something working, but just barely. Now you’re in fix it mode. Hacking away at it, trying to salvage it, trying to mold it into something usable.

It’s not that bad, you say. A little refactoring here, some more over there. Patch this, whack that. Oh wait, shouldn’t I be testing this?

I just went through this and caught myself before I went too far down this rabbit hole.

The idea is a digital picture frame app for the iphone using images from Facebook. Sure, there are apps that already do this, but I wanted some exposure to the Facebook api. I also wanted to do a relatively small iphone app before I dive into some of my other ideas for projects.

It was going along pretty well. I wrote some code to pull down pictures from Facebook. I had some code that cycled through the pictures. Then I started trying to shove more feature into it. I definitely need some settings, right? Where will the Facebook connect button go? I’ll definitely need some background threads!

As I started on my third pass of refactorings, I realized what I was doing…poor code didn’t know what hit it.

Now, taking the lessons learned and some code snippets (for reference), it’s time to toss the proof of concept into the trash bin. It’s where it belongs.

As some may or may not have heard, I started freelancing on the side.  My first side project is pretty interesting ( was interesting if your reading this in the distant future.)  Basically, the project was to talk to different devices and provide status information back from the devices through an LCD panel.

Pretty straightforward.  Oh wait, it has to run on an EPIA platform.  Also, Windows XP isn’t a viable option…

Hello Linux and Mono!  Did I mention that my preferred language is C#?  I’m not a fan of writing C or C++ since I drank the .Net Kool-Aid back in 2003.

Surprisingly, my development platform of choice (Vista and VS 2008) and the target platform (Linux + Mono) work out well.  Really the only hiccups I’ve encountered have been with the project files and NUnit.  If I create a test project in VS2008 and open it with MonoDevelop (on the Linux development machine), it can’t seem to locate that NUnit assemblies, but after I correct it in MonoDevelop, VS2008 doesn’t have a problem with it.

Maybe it’s just me, but the ability to run the same code on two different platforms makes me happy.  And it’s crazy easy to run a Mono development environment.  Just download VMware’s player, download the virtual machine for the Mono development environment and run…it rocks.!

Actually, I fibbed just a bit…there’s been one other issue with Mono that kind of annoys me.  It’s with the implementation of the SerialPort class.  Basically, the SerialPort class has no notification for received serial data.  It’s pretty easy to work around this (it involves polling the SerialPort and works on Windows just as well), but it is a pain point.

So, if you find yourself needing to do cross platform development in .Net, check out Mono.

Git is the new hotness.  There are other distributed version control systems, but git seems to be the one that’s taken off the most from what I’ve seen.  There’s Mercurial (the command “hg” is pretty sweet) or Bazaar (does anyone use this?), but it seems that most all of the projects I’m interested in that use dvcs are using git (I’m looking at you IronRuby.)

Git may be a bit confusing when you first start working with it, but fortunately, http://gitready.com/ has a bunch of tips for dealing with git day to day.

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.