This was kind of a wild episode, inasmuch as recording oneself writing code gets wild. This was the second bug driven out by the acceptance tests, but this one was subtle and buried fairly deep in the application logic. This was another half hour episode as I employed a variety of techniques for hunting down and fixing a bug.
What I accomplish in this clip:
- Fixed the bug discovered last time.
- Left a few legitimate tests as breadcrumbs along the trail.
Here are some lessons to take away:
- Use binary search kinds of techniques when solving problems. For instance, if a two part boolean expression is causing a test to fail by returning the wrong result, comment out/delete one of the branches to see which one it is. This helps you narrow the search without invoking the debugger or squinting at the code, scratching your head.
- It’s important, when you have a failing acceptance test, to drill in and recreate the scenario in unit tests with less setup context around it. This ensures that the problem is, in fact, a problem of the code under test rather than something going on with the acceptance test setup. Getting this second failing test prevents you from chasing phantom bugs in your production code.
- I try to use the debugger as little as possible when doing TDD, especially with the continuous testing tool. But, for the occasion that you’d have to write a lot of assumption checking asserts, the debugger can be a handy way to see a number of different values that you want to check. This was relevant when I wanted to see 4 different coordinate values.