Stories about Software


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.

Newest Most Voted
Inline Feedbacks
View all comments
9 years ago

“Seriously, what advantage is there to that being mutable.” I can think of one reason: Designing for immutability might drive the design of the code from being very flexible and easy to use to one that is not. The first example that comes to mind is a simple object like this: class Point { public int X { get; set; } public int Y { get; set; } } and turning it into: public Point { public Point(int x, int y){ // .. } public int X { get; } public int Y { get; } } Congrats, we’re immutable!… Read more »

Erik Dietrich
Erik Dietrich
9 years ago
Reply to  darrencauthon

The class I was talking about represents a chessboard, so what I was talking about, specifically, in that statement is the dimension of the chessboard. What I’m interested in not having to think about is handling a case where someone using this class creates a standard chessboard, populates it with pieces, and then decides, for some reason, to reduce the chessboard to 4×4 in size. I can’t think of any reason to allow this. I have a few miscellaneous thoughts on the hypothetical class you’re talking about, Point: (1) I probably wouldn’t write tests at all against the class you’re… Read more »