Chess TDD 19: DoesPieceExistAt and Housekeeping
Another night in the hotel, another episode of ChessTDD. I’m doing my day to day work mainly in Java-land these days, so this is about the only time I write .NET code anymore. Anywho, in this episode, I’m just planning to pick some housekeeping cards and move them across, starting with one I created after receiving an astute observation from Jeff in the comments from last episode.
Here’s what I accomplished in this clip:
- Fixed a subtle bit of weirdness that may have caused future problems.
- Cleaned up the screwy logic around default board size.
- Factored the test classes more toward the new naming paradigm.
- Implemented a DoesPieceExistAt() method to get away from GetPiece() == null
Here are lessons to take away:
- This is kind of a combined lesson from last time to this time. The comment I received and my resulting attention to the issue he pointed out is an excellent example of why pair programming (or at least code review) is full of win. I may or may not have caught that logic error before shipping this thing to (an imaginary) QA or production, but with that review, it’s at the fore and I can do something about it.
- “Boy Scouting” isn’t just about improving production code. It applies to anything, including your tests. Wholesale, quixotic refactoring efforts are not necessary if you’re constantly improving the code a little bit in the areas that you’re touching anyway. In other words, you needn’t always go out of your way to refactor — it’s often advisable to wait to touch production code until you’ll be in there anyway.
- I like to default to immutability whenever possible. In the case of board size, why make that a settable property? How often does it come up that you want to change the size of a chessboard that already exists with scissors or tape and cardboard? (Modeling the physical world just makes for a funny mnemonic — faithfully modeling it isn’t actually that important.) Seriously, what advantage is there to that being mutable. In my book, none. You want a different board size, make a new board. Not having board size be mutable makes your life much easier — no reasoning about what happens if you shrink the board when pieces are on it and other things like that.
- Class level preconditions passed into a constructor are important to guard against. Don’t let your consumers pass you things that would render you in a nonsensical state, such as accepting negative 1 as a board size. When this happens, fail quickly, loudly, and visibly with an exception, and make it clear why and how in your tests.