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.