Chess TDD 16: Finishing Bishop Blocking

Once again I’m bringing you this code-cast from a Marriott, albeit a different one. In spite of a bizarre amount of noise over the course of the evening for a business hotel, I’ve managed to get at least passingly decent audio for this (and for some ongoing Pluralsight work as well). This is a pretty workmanlike episode where I dive into the refactoring I didn’t have time for last weekend and then use the resultant code to make my life easier as I finish the bishop implementation.

Also, as a quick aside, someone asked me a little while back for some advice about how I approach integration/system testing, and I was thinking I might just plow through this series to demonstrate where and how I’ll start bringing in broader tests. So, stay tuned for that, probably whenever the blocking implementation is finished.

Here’s what I accomplished in this clip:

• Refactored a seriously bad piece of code for diagonal blocking.
• Fleshed out the diagnoal blocking to handle all cases.
• Satisfied myself that diagonal blocking is reasonably robust.

Here are lessons to take away:

• If you’re not sure what to name a method that you’re pulling out, don’t interrupt your flow by obsessing over what to call it.  Naming is extremely important and you definitely want to come back to it, so just call it something like “Dunno()” and focus on the refactoring for the time being.  That silly, glaring name will prevent you from forgetting to come back and think through the name when you understand better what you want to do.
• Oops.  Didn’t pay close enough attention to my little NCrunch notifier going red during a refactoring.  When that happens, don’t say, “uh oh” and go trying to fix the problem.  Start hitting undo until you’re green again.
• Whenever something you want to do to the code strikes you, hurry over to Trello (or Excel or whatever) and add it.  TDD makes it easy to pick up where you left off, but you’ll often forget about stuff you want to do if you wait to note it.
• If you’re not totally comfortable with your implementation, it’s perfectly fine to write a test that you expect (okay, maybe hope) will go green and then move on, more confident, when it does.  TDD discipline says that to change the behavior of production code you need a red test.  It doesn’t say that you always have to write tests expecting them to go red.  Anything that tells you more about the system or increases your confidence in it is a benefit.