Chess TDD 53: Castling for Black Pieces
After a couple of episodes working on castling for white, and then an episode refactoring that implementation, it’s finally time to implement castling for black pieces. This actually went pretty well. The groundwork that I had laid in the previous episodes made life a lot easier for me here. It wasn’t perfect, by the end, but it’s getting encouragingly close to “good enough to move on.” With castling and en passant both soon to be in hand, it may be time to move to clean up mode with more elaborate acceptance scenarios. A light at the end of the tunnel?
What I accomplish in this clip:
- Finished basic implementation of castling checker.
Here are some lessons to take away:
- It’s pretty rare to extract a class, find testing a lot easier on it, and then, at the end, come to regret extracting the class. When you find yourself banging your head against the wall in a growing iceberg class, extract!
- Refactoring to clean code makes it a lot easier to hit the ground running when you come back to your code after a while.
- The goal of test driving a production code base is not to address all possible inputs to the thing under test. You test drive until the implementation is done. If you continue to write green tests after that, you’re no longer test driving. There’s nothing wrong with this activity, but take care that you’re not adding cruft instead of value to your code base.
- I wrote maybe 10 tests to drive the implementation of castling for white pieces, and then something like 3 tests to make it also apply to black pieces. This is normal. Just because I wrote 10 tests to get 50% of the functionality does NOT mean that I have to write another 10 tests to get the other 50%.