ChessTDD 25: Yak-Shaving with a visit to trusty old ExtendedAssert

I started out with the intent of cleaning up a mistake in the new board setup functionality and moving on to more acceptance tests.  However, I got sidetracked a bit and wound up adding some functionality to my ExtendedAssert utility and briefly contemplating the interaction of some things in my object graph (once a week is better than I’d been doing, but 20 minutes per week isn’t a lot of time to keep it all fresh in my head).

Here’s what I accomplish in this clip:

• Get at least a start at having tests around PiecePositioner
• Fixed the issue where SetupStandardBoard was making both pawn rows white
• Added functionality to my ExtendedAssert utility.
• Added a way for consumers of the Board class to tell what size the board is after creating it.

Here are some lessons to take away:

• I make a lot of dumb mistakes.  It’s TDD and the trusted test suite that helps me flounder for times on the order of seconds looking for them, rather than frustrated minutes or hours.
• If you can avail yourself of NCrunch, I highly recommend it.  It’s incredibly handy to be able to visualize the path through the code that your unit test is driving.
• A valuable part of TDD is stopping to reason about what your public methods will do when you feed them nonsense.
• Duplication is icky anywhere you find it, including customized assert utilities.
• Writing test infrastructure code (e.g. custom asserts) gets deeply weird in a hurry, since you have to either write unit tests for the unit test helping code or else flip the script and use your production code to ‘test’ what you’re doing in the test code.  I favor the latter approach.  Test and production code are like balancing your check book, so it seems reasonable to me to use either one as validation of the other.  YMMV.