TDD Chess Game Part 4: Getting Organized

Alright, welcome back to this series.

A couple of housekeeping things:

1. I have bitten the bullet and used the Visual Studio White theme along with 14 point font to record, so hopefully the videos going forward should be easier to watch. It’s a little surreal to work with, but c’est la vie.
2. The source code is now available on github for you to follow along. The coding is usually running ahead of my publication, so if you want to see the code from a given video, you may have to grab a slightly earlier version.

Here’s what I accomplish in this clip:

• Started using a little todo list to keep track of what I’ve done and what I need to do.
• Cleaned up code as reported by static analysis tools.
• Pulled some production classes into their own namespaces and out of the test classes.
• Defined an abstract Piece class.
• Defined a second inheritor, “Rook,” for Piece.
• Defined a bit of dumb functionality for Rook’s “GetMovesFrom” to get it started.
• Implemented ability for a pawn to move two spaces on its first move.
• Defined a piece concept of “HasMoved.” (albeit just for Pawn)

And here are the lessons to take away:

• Keeping a list of smallish things you want to change can help you keep track of what needs to be done without distracting you too much (I picked this technique up from Kent Beck’s “Test Driven Development By Example.”)
• If you’re using NCrunch, use the green dots being dark or bright as a quick way to tell if the code is compiling.
• Gamify cosmetic issues. If “Optimize Namespaces” and things like that are important, make violations ugly and distracting in the IDE and you’ll get annoyed and fix them whereas you probably wouldn’t bother, otherwise.
• It’s okay to write stupid tests if you do so knowing that you’ll fix them. Finding ways to always write a test to change production code is good for practicing the TDD discipline until it starts to become second nature.
• It’s okay to write a test that causes a non-compile failure and then needing to do a good bit of work to get everything back to compiling/passing.
• I’ve mentioned this previously, but it bears repeating: it’s okay to reuse a test (especially a stupid one) to get a failing test.
• If you weren’t aware of C# yield keyword and deferred execution, it’d be a good thing to familiarize yourself with.
• Force yourself not to copy and paste as much as possible, even when it seems dumb. Feeling the pain of re-typing things will make it painfully obvious when you’re duplicating code and could do something better.

And, here’s the clip: