About this TDD business...

I suppose to most of you this concept would seem obvious; but I'll try and lay it out simply.

When you start working on something using Test-Driven Development, you're trying to capture the behavior of an entire system, or subsystem at a time... at least that's where you start.

You focus hard on the responsibilites... or "what you want the code to do". So, you pick a responsibility, or "responsibility set" and start off. These are often called "user stories".

First things last

I'd been working this way, at a high level, and was noticing that several of the requirements were always breaking down, themselves, into more "atomic" steps. So I'd write out the sub-requirements... but afterword, I'd go back and try to keep implementing this now "larger" responsibility set FIRST.

The difficulty I'd been running into is that to work with these "larger concepts" (which usually map directly to a "class"), you have to "stub out" the dependencies (or "smaller classes") so that you could keep working. What I call "stubs" for these "smaller classes" or responsibilities are called "Test Doubles".

Forehead Smacked

What I realized tonight, after working on a much narrower responsibility set with no dependencies, is that the smaller, more atomic stuff, is much easier to test! D'oh!

Here's the problem in a nutshell:

• To write a "Test Double" (or Stub/Spy/Mock/Fake), you have to know something about what you are stubbing... or what your SUT (system under test, or "tested class") will need. In other words, you have to break away and do a little design on THAT... at least the new interface.


• It takes extra time to create these Test Doubles


• Often as you're working along, and you finally get to start testing the smaller depended-on classes, or DOCs, "into existence"... you'll find that you didn't capture enough of this class' responsibilities when you test-doubled it for the larger class... so you have to retro-fit your larger class for new functionality

Pain, the greatest teacher

The last one in the list is usually the most painful; but it's not that bad, ironically, because you will have tests in place ... so that if you "screw something up" trying to make your larger class work with the new requirement, you can just make the tests pass again... and you're good to go.

So maybe... I don't know... I need shot in the face for my refusal to see this clearly from the start.... but now this concept is out there... and maybe it can help you avoid shooting yourself in the face.

Whiteboard whitewash

I've updated my whiteboard... for comparison with the old one... if anything ... it's interesting to me [smile] ... but I do think it's keeping me on-track.

Love ya!


C