Chess TDD 61: Testing an Actual Game

Editorial Note: I was featured on another podcast this week, this one hosted by Pete Shearer.  Click here to give it a listen.  It mostly centers around the expert beginner concept and what it means in the software world.  I had fun recording it, so hopefully you’ll have fun listening.

This post is one where, in earnest, I start testing an actual game.  I don’t get as far as I might like, but the concept is there.  By the end of the episode, I have acceptance tests covering all initial white moves and positions, so that’s a good start.  And, with the test constructs I created, it won’t take long to be able to say the same about the black pieces.

I also learned that building out all moves for an entire chess game would be quite an intense task if done manually.  So, I’d be faced with the choice between recording a lot of grunt work and implementing a sophisticated game parsing scheme, which I’d now consider out of scope.  As a result, I’ll probably try to pick some other, representative scenarios and go through those so that we can wrap the series.

What I accomplish in this clip:

• Get re-situated after a hiatus and clean up/reorganize old cards.
• A few odds and ends, and laying the groundwork for the broader acceptance testing.

Here are some lessons to take away:

• No matter where they occur, try to avoid doing redundant things when you’re programming.
• If, during the course of your work, you ever find yourself bored or on “auto-pilot,” that’s a smell.  You’re probably working harder instead of smarter.  When you find yourself bored, ask yourself how you might automated or abstract what you’re doing.
• When you’re writing acceptance tests, it’s important to keep them readable by humans.
• A seldom-considered benefit to pairing or having someone review your coding is that you’ll be less inclined to do a lot of laborious, obtuse work.
• Asserting things in control flow scopes can be a problem — if you’re at iteration 6 out of 8 in a while loop when things fail, it’s pretty hard to tell that when you’re running the whole test suite.

Chess TDD 47: En Passant in the Other Direction

It’s been a while since the last episode, due mainly to my wedding and honeymoon, but here I am, back in action.  For some, there were a few audio glitches in the recording of this episode.  I did just upgrade to Windows 10, so maybe my version of Camtasia isn’t playing nicely with or something.  My apologies, but I think it’s just minorly annoying and not a problem for understanding.  This episode is pretty straightforward.  I performed a little bit of cleanup on naming and then finished up by implementing en passant in the other direction.

What I accomplish in this clip:

• Fixed some naming hangover from last episode.
• Got en passant working in the other direction: white pieces capturing black pieces.

Here are some lessons to take away:

• I’ve said it more times than I can count, but naming is so important.  Spend extra time with it.  Revisit it.  Make your methods as readable as progress.
• When you’re test driving (or, at least, making sure to write a lot of automated tests), the kinds of refactorings that a lot of people promise to do ‘later’ and never do turn out to be a lot easier.  You’re much more likely to deliver on promises to clean up later.
• If you have logic that you want to test and it’s 2, 3 or more calls deep in private methods, this is often a sign that you should extract a class and have two different public surface areas to test.
• If you can delete a line of code in your code base and no test goes red, you’ve failed at some point in your test driving.  Either you’ve deleted a test that should exist or else you’ve added functionality to prod without having a failing test that requires that addition.  It happens to the best of us, but understand that it’s a problem and either delete that code or add a test that makes it necessary.