By way of explanation

15May06

I’m really enjoying doing test-driven development. For those of you who don’t know what that is (and care to learn), test-driven development is a different way of writing software that makes it easier to track down bugs (defects) in your software.

That sounds boring, but it’s really not. Imagine I want to write a bit of code that takes a photo and makes it awesome. Traditionally, one might start by writing some code:

function MakeImageAwesome(Photo)
 {
     Load(Awesomanator);
     Awesomeanator.PrepareImage(Photo);

    etc...
 }

With test driven development, before you start writing any code at all, you write a test that checks whether your not-yet-existant code works:

[Test]
TestAwesomeFunction()
{
  PhotoOfErik = Flickr.GetPhoto(”Erik’s Self Portrait”)
  AwesomePhoto = MakeImageAwesome(PhotoOfErik)

  Assert.IsTrue(AwesomePhoto.IsReallyAwesome)
}

This way, I can run the test, and see that no… my function is not yet making the photo of me awesome. Then, and only then, do I start writing the awesome code. As I am writing code, I can continually check my progress.

This might seem trivial, but it makes a BIG difference on big development projects. You end up with thousands and thousands of little tests, so if you accidentally break something that used to work, you know right away. And something is not working, you can narrow it down a lot more easily: all the tests that pass are obviously NOT the problem.

The real kicker is that when you do discover a bug, despite the fact that all your tests are passing, you don’t start fixing the bug. You start trying to write a test that would expose the bug. As soon as you get a test that fails, you start writing code to make it pass. That way, you know when you’ve fixed the bug, and you know that if it ever comes up again, you’ll be aware of it.

The only thing that is making this process less fun is that Nunit is constantly crashing on me whenever it reloads my project. I have to close it and reopen it each time. That’s obnoxious.

But seriously: I heartily recommend this approach for anyone who is writing any kind of code. I’m finding it really valuable even on small scale things.

1 Response to “By way of explanation”


  1. 1 Kynthia Posted May 17th, 2006 - 3:17 am
    [Test]
    TestAwesomeFunction()
    {
      EriksExplanation = snowedin.GetExplanation(”By way of explanation”)
      AwesomeExplanation = MakeExplanationAwesome(EriksExplanation)
    
      Assert.IsTrue(AwesomeExplanation.IsReallyAwesome)
    }

    green circle!
    :)

Leave a Reply


Comment guidelines: No spamming, no profanity, and no flaming. Inappropriate comments will be deleted outright.




Where am I?

This is a single entry in the weblog.

"By way of explanation" is filed under pi. It was published in May 2006.

May 2006
M T W T F S S
« Apr   Jun »
1234567
891011121314
15161718192021
22232425262728
293031