ChessTDD 12: Blind Alleys

This is one last post of loose ends and looking at what I’ve done so far before I move on to new functionality.  It wasn’t necessarily my finest hour as a programmer and TDD practitioner, but I’m including the good with the bad because nobody is always on when programming.  Also, I wasn’t insanely on in terms of my audio recording either becasue my throat was a little scratchy today.  You might hear me stealing quiet sips of ice water from time to time.  Anyway, here’s what I accomplish:

• Reworked the knight’s GetMovesFrom() method
• A fair amount of design flailing

Here are some lessons to take away:

• An interesting side effect of a long time spent at TDD is a tendency to look to unit tests when wanting to dive into and explore code functionality.  The reason for this is that you know the unit tests will show you how the class’s public API is being used.  So, it’s like finding the class instantiated in-situ in the code, except that in the test class, it’s going to have a bunch of methods with descriptive names telling you how things work.
• When doing exploratory refactorings, try to keep things compiling as much as you can and check with as much granularity as possible that you’re still passing.  Some of my flailing with tuples of ints wasn’t really necessary, but I kept my eye on the tests anyway so as not to get stuck in the middle of a refactoring where tests are red, things are broken, and I don’t know how to go forward or back.
• Check out around 9:50.  Copy and paste will always burn you.  Even when it’s tiny.  Even when you’re using TDD.
• Sometimes you wind up in a blind alley.  That’s okay.  Go back to where things were working and tackle the problem again later.  This isn’t just punting; it’s an important skill.  You need to ship code and you can get lost in trying to perfect it if you aren’t careful.  So, let it go, think on it later — in the shower or while eating dinner or something — the answer will smack you in the forehead like a ton a bricks at some point.

TDD Chess Game Part 9: God Save the Queen

As always, it seems that I’ve let too much time elapse between iterations of this series. This time my excuse was worse than ever. I actually had this video ready to go last Friday or something and then the post was was queued up on Sunday, but I was too tired when I got home on Sunday night to remember to go publish it. Anyway, it’s live now.

Here’s what I accomplish in this clip:

• Implement Queen with GetMovesFrom()
• Add more common functionality to Piece base class.

Here are some lessons to take away:

• For the most part, in the last number of clips things had gone more or less as I expected.  Here you got to see the value of the test suite indicating to me that I was reasoning about the code incorrectly.  I didn’t realize that the GetRadial methods were returning only moves N spaces away rather than up to and including N spaces.  It took some floundering to figure this out and, without red tests telling me things were going haywire, I probably would have plowed ahead for minutes or hours before I realized things weren’t working.
• Pulling up functionality into a common base class is a way to avoid duplication and make tests go green rapidly, but beware of creating a base class abstraction that’s awkward just to reuse code.  If it seems awkward, it might be worth creating a class that your ancestors use.  So far, the functionality in Piece seems to make sense, but I’ll keep an eye on this.
• Use Intellisense in a savvy way.  When you notice a few times that what you’re expecting to happen isn’t happening, that’s a yellow (if not red) flag.  Late in the video, this kept happening to me, and it turned out to be because I had spelled “radial” as “raidal” when defining a method.  Typos, incorrect assumptions, etc — often these things can be revealed by the IDE not behaving as expected.
• Definitely keep track of refactorings you’d like to do in you list.  Treat these as if they were no different than features you want implemented.