Stories about Software


Chess TDD 17: Implementing Piece Movement

In this episode, I switched gears a bit to focus on the comparably easy task of moving pieces. I’d had enough of wanting to move pieces for setup, so it was time to take care of that.  I also might (will at some point) revisit the test classes and perhaps consolidate to always starting with the normal board and adding/removing as needed for setup.

Here’s what I accomplished in this clip:

  • Renamed that method from last time.
  • Added basic implementation of move.
  • Added a bit of parameter checking for move.

Here are lessons to take away:

  • Simplicity isn’t just for “do the simplest thing to make it pass.”  It applies on the test side as well.  I started to implement MovePiece() by moving a piece two squares away, but moving it one square away is sort of a simpler case, so it’s probably better to do that first.  The same kind of logic doing, say, prime factors.  Start with 2 — don’t start with 2497.
  • When deciding what test to write next, imagine how you might break up the work that needs to be done in terms of decomposition.  When I was writing MovePiece(), I thought, “move piece means delete a piece from origin and add a piece to destination, so I’ll write a test that accounts for one of those things only: piece exists at destination.”  MovePiece() may seem simple, but it’s decomposable, so let that guide your testing effort.
  • If you think of a refactoring for the test method while you’re writing it, just keep writing the test.  Go red then make it green, then do whatever you’re thinking in the refactor phase.  Having a half-written test is no time to start refactoring.
  • TDD makes you the first consumer of your API.  View your API through someone else’s eyes and use that to make your code better.  I discovered that I could accomplish RemovePiece(Coordinate) by calling the existing method AddPiece(null, coordinate).  But that’s weird and awkward from a semantics perspective.  What strikes you as awkward as you’re coding will strike your consumers as confusing, maddening, or horrifying.  Don’t put them through this.

newest oldest most voted
Notify of
Robert Bonham
I’m loving this series (although I’m only on #5), and have just picked up your ‘starting to unit test..’ book on amazon. At work we’ve undertaken a project much larger than we usually take on (year long vs month long) and the size and complexity of the codebase as we go is overwhelming us and revealing our inexperience in designing a larger project. My task is the financial section and although its becoming quite functional, it’s not at all testable and it getting unruly when it comes to change. My code in places reminds me of the old ‘choose your… Read more »
Robert Bonham

Earlier today I wrote a long post asking advice on how to approach starting to unit test a large codebase that’s become unruly that I’ve recently written. Which I’ve now deleted because…..

Even earlier today I’d bought your book on getting started unit testing on Amazon.


Just read chapter 5 on “invading legacy code in the name of testablity”…best $5 I’ve spent on a book ever.

Thanks for giving back to the dev community.

Jeff LeBert

I agree. Go buy and read the book. It is well worth the $5. Also go read Code Complete. It’s a huge book but well worth your time. I hadn’t though about it before but this but I guess I’ve just put your book in my list of must read for any programmer. 🙂

Erik Dietrich

Wow, thanks (and thanks for supporting me with by buying the book)! I’m flattered at that designation and especially to be mentioned alongside of Steve McConnell. I’m hoping to have a few more coming over the next year or so as well, so stay tuned. 🙂

Erik Dietrich

Thanks for supporting me and buying the book! Hopefully that chapter helps, but if you’d like more specific advice, I do have some experience with testing patterns around EF and the entities that it generates.

Robert Bonham

Thanks Erik, currently I’m taking the advice from the book (or at least how I interpreted it) of thoroughly documenting what my code writes the the DB for various events (payments, voids, cancel fees when payments have been made, etc). That in itself is revealing some re-factoring opportunities, which will lead to what I hope will be a series of testable points in the code.