Stories about Software


ChessTDD 21: False Starts and The Knight Problem

This wasn’t the most productive episode I’ve ever recorded, per se, in terms of functionality, but, hey, it’s always a learning experience to write code.  This was kind of table setting for a big, important piece of functionality: distinguishing captures from blocked moves because of friendly pieces.

Here’s what I accomplish in this clip:

  • Flesh out the non-happy path scenario for PathChecker (later renamed PathMaker)
  • Start implementing functionality for Knight on the board.

And, here are some lessons to take away:

  • If you write a test that you think should pass and it fails, it’s okay to pivot what you’re testing to gain understanding.  Improving your reasoning about the code is extremely important.
  • Thrashing can happen.  It occurred to me that GetSpacesAlongPath maybe shouldn’t return the destination piece in its collection, but that created problems for existing code.  I weighed the dependencies and what would need to change the functionality and decided clarifying the name was a better route.
  • It’s okay to write and leave tests to confirm your hypotheses.  The TDD discipline is to force yourself to change production code only in response to a failing unit test, but there’s nothing to say you can’t write green tests to confirm that the system is working as you expect.  I have no qualms about weaving this sort of thing into red-green-refactor provided that the test is one that is meaningful when left in place because it’s important to corroborate your reasoning about the code.
  • Don’t call it a day with a failing unit test.  If you’re not prepared to finish by making it green, back it out and add a todo list item.  You don’t want to start at red next time.

Newest Most Voted
Inline Feedbacks
View all comments
Geoff Mazeroff
Geoff Mazeroff
9 years ago

I understand the concept of not leaving off with a failing test. Presumably you’d push that to a remote repository and anyone looking at it would have no idea what’s going on.

On the flip side, I think I heard a guest on .NET Rocks! say that he uses failing tests during context switches. For example, if you’re about head into a meeting, leave a failing test around what you were doing so that you can very quickly regain that context and pick up where you left off. I believe Trello solves that problem for you in this case.

Erik Dietrich
9 years ago
Reply to  Geoff Mazeroff

Yeah, I like the approach of failing test (or non-compiling code) as a bookmark. In this case, though, I’m publishing the changes to the public master repo after each commit for anyone following along with the code. I wouldn’t want them to grab my code and think I was wont to commit and push with broken unit tests 🙂