Test Driven Development: Building Lots and Lots of Miniatures

Learning test driven development has been an adventure. As I have learned to use, and appreciate the process, it has really driven home in my head the opacity of programming. I have been trying to learn to code the same way I would do if I were building a watch. Insert a piece. Turn the wheel. See if it all moves. On an intuitive level that should work. There seem to be lots of moving parts in the program I am writing, but at the same time, it is also very static. All the moving happens inside the computer’s memory where I can’t easily see it, and there are lots and lots of parts moving.

In my recent work in operations, I can make a change, watch the process, identify the sticking point and correct it. There might be subtle things that affect efficiency that I can’t identify without careful tracking of statistics, and there are definitely times that it would be helpful to be way up high so I could see the whole process at once. But it is very accessible to me, I can see it happen.

Returning to my previous post on programming in the theatre, when I programmed a cue into the system, and ran it, there were two ways for me to me to track the changes as they are executed. First, the actual physical lights change. I can see them turn on or dim. If the output isn’t what I want, I can just look up and see which lights aren’t right (that’s how lighting designers die, too busy looking up at the lights to notice the orchestra pit). There are also two monitors attached to a lightboard and at least one of them is dedicated to displaying the progress of cues as they run. Every channel number is listed and the level at which it is set is displayed below it. As the cue runs the levels change.

When the output isn’t right, say a light comes on that shouldn’t, I can compare the monitor to the light and get a lot of information about where the problem lies. If something goes out that shouldn’t, I can watch the program run to figure out where it goes out and why. I can see the cogs moving.

It is possible a tool might exist to display what’s happening in memory, I know I have seen simple versions in debuggers for example, but I haven’t seen a tool that displays it in any large scale. Clearly time is also a big factor in this. The process in an operation might take days, a lighting cue can take minutes, but a computer program (hopefully) runs in fractions of a second. Even if there were a transparent display I couldn’t read it fast enough to find the problem.

So, in the end, it’s a sort of fundamental shift. Instead of monitoring the whole process from start to finish, testing takes the code in chunks, and runs them separately, out of the context of the larger process. Clearly this is useful in that it allows you to make sure that the whole code is working without having to run every single process in an application, but building a whole new instance for every test it is still a little mind boggling. It’s like building the same miniatures over and over again to make sure the plans are still good. Now, the metaphor isn’t perfect for a number of reasons, not the least of which is that one doesn’t typically make thousands of revisions to one’s building plans. I suppose if one were to do so, it would make sense to build a miniature after each revision, just to make sure the pieces still fit together. But it is still really difficult for me not to picture an entire studio filled with teeny tiny furniture.