TDD In Your Fingers

I’ve been pair programming with some new developers who are less familiar with Test-Driven Development, as well as giving a talk on a similar topic for the Imperial College Web Design and Software group. So after a break from hands-on programming, I’ve been doing TDD myself a lot this week, and I noticed that a lot of it is in your fingers!

TDD gives you an itchy test finger. You should run your unit tests every time you have compiling code. If this doesn’t happen very frequently – about every 1-2 minutes for my coding speed – something isn’t right, because you aren’t getting the benefit of extremely rapid feedback on the state of your code. I feel myself reaching for F11 (the Eclipse shortcut) on a regular rhythm; if I draw back this itchy finger once or twice because my code isn’t compiling at that moment, I start wondering why I haven’t got testable code and looking for ways to get there fast.

Your fingers should hurt if you have too many dependencies. For each class used by the class under test, you have to inject the dependency and then get its behaviour, either by using the real class or a mock object. Do this more than two or three times and your hands should be cramping up from all the typing. Don’t ignore it, or worse yet give up on the test; the pain is a signal that your class is too busy. Step back and figure out how to reduce the dependencies – often this involves introducing one or more additional classes.

Please pipe up if you know of other ways TDD helps keep your fingers typing good code.

2 thoughts on “TDD In Your Fingers”

  1. Somewhat tangentially related, having recently been writing some MIPS assembly, I can definitely say that I missed being able to do TDD! (At least, I don’t know a straightforward way of doing TDD with assembly.) It’s hard enough to work out what some piece of assembly code is doing, let alone whether it’s correct or not.

    I still suffered from an itchy test finger though, so if I wrote even a small number of lines, I made sure they did what I expected, usually by dumping out the contents of registers or memory to a display. Of course, the downside is that there’s no quick way to check for regressions – once you’ve put in the little test snippet and made sure your latest change works, you get remove the snippet and carry on.

  2. Thanks Mike! I bet you could write a simple xUnit framework for assembly language – all it would have to do is call your subroutine with known inputs (of course we’ve organised the code into subroutines with clear responsibilities, right?) and then compare register contents to expected values. Checking memory might be a bit more difficult but should still be possible. I’d be inclined to write most of the framework in something like C and just call out to assembler where needed (e.g. to extract register values).

    Sounds like a fun slack-time task to me!

Leave a Reply

Your email address will not be published. Required fields are marked *