Chess TDD 50: Back to the Green Field (Kinda)

Editorial Note:  These videos appear on my Youtube channel, but I’m starting to do a lot of other things there as well, including an upcoming series that I’m going to start uploading soon.  If you like the series, it’s probably worth subscribing to the channel.  You can subscribe by going to this link and clicking “Subscribe.”  

This time around, I actually get to do a bit of green field development again.  That sounds like a weird distinction to make, but I’d been so involved in modifying the existing pieces and the board class that biting the bullet and creating a class to handle castling was a huge relief.  I had fun this episode — so much so that I already coded 51.

What I accomplish in this clip:

• Created a class to evaluate boards for castling opportunities.
• Started the castling implementation in earnest.
• Proved to be really bad at telling X and Y coordinates apart.

Here are some lessons to take away:

• As with assemblies and namespaces, having dependency cycles with classes is a bad idea.  If class X knows about Y and Y knows about X, these should probably be the same class.
• When testing additional scenarios is a huge chore and you’re frequently having to worry about breaking lots of other tests, it may be an indicator that you’re cooking up an iceberg class.  I noticed this in the form of pain I felt when doing things to the Board class and the comparable joy I felt in this relatively green field work, today.
• Tradeoffs are everywhere in your software development process.  Refactoring while red is a risk, which I did without thinking to rename a method parameter.  But not renaming the parameter is also a subtle risk because I might forget to do it while getting to green and leave a sub-optimal name in there, possibly causing a future developer to make a mistake.  This is not to excuse my own mistake, but rather to point out that there tend not really to be “right” and “wrong” as often as we think.
• It’s really easy to make dumb mistakes and we all do and will.  TDD as an approach is so helpful because it mitigates the dumb mistakes by shortening the feedback loop between when you make them and when you notice them.