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.
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.
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 🙂