ChessTDD 37: Cleaning Up and Implementing Rook
Got back in the saddle with this episode, and had a shorter recording that basically went well. Someone pointed out in the comments that I had reversed king and queen position for the black pieces, so I started off by fixing that, and then moved on to fixing a bug and finally implementing the Rook acceptance tests. Wrapped it up in relatively short order, too.
What I accomplish in these clips:
- Fixed my template for the full chess board.
- Fixed the vertical version of that reverse bug from last time.
- Implemented rook acceptance tests.
Here are some lessons to take away:
- It’s important to understand past shortcomings of your code so that you can form good hypotheses about where you might have other potential weak spots.
- If you’re going to run an experiment on your code, do it from a test that you’re writing instead of through the GUI or the debugger or something. You’re running the experiment anyway, so you may as well capture the results in the form of an automated regression test.
- A lack of test coverage for a line of code isn’t a problem in and of itself. Coverage is a metric and not a goal. The problem with having code not covered by tests is that there’s nothing to prove that the code was implemented in a thoughtful, deliberate way. If you don’t have a test expressing what a path through the code is supposed to do, there’s no way to know if you’ve reasoned about that code.
- Copying, pasting, and adjusting often winds up taking longer than typing by hand. You spend more time staring dumbly at the screen trying to figure out what’s wrong than it would have taken you to hand type the code you need.