In this episode, I start to discover that castling is hard. There’s unusual movement, the fact that 2 pieces move simultaneously, and the fact that you have to keep track of a lot of status. People have even commented on this being a particularly hard facet of the game. Oh well, c’est la vie. I think I came up with an idea for a helpful strategy during the course of this episode, even though this episode itself wasn’t wholly productive.
One thing to note if you’ve been following this series is that I’ve switched to Visual Studio 2015. I brough CodeRush, NDepend, and NCrunch along for the ride, not to mention some of my preferred VS plugins. If you want more information on stuff I use, check out my resources page.
What I accomplish in this clip:
- Fixed castling implementation to the long side of the board.
- Got a little more organized in Trello.
- Started on implementation of not allowing castling when pieces have moved.
Here are some lessons to take away:
- When you need to correct a mistake or bug, make sure you start with a red test that exposes the mistake.
- It’s okay to have a situation where making a test you’ve altered green makes others red. If those tests are now wrong or out of date, this gives you basically a checklist of the tests you need to fix.
- If you consider yourself advanced enough to skip a step, it’s still always possible that you’re making a mistake. TDD is all about micro-hypotheses and verification of your understanding of the code. If you find yourself being wrong, slow down and get back to basics.
- No matter how long you’ve been at this, you’ll still make mistakes, especially if you get a little fast and loose.
- If you write a test to confirm your understanding of behavior in a certain context, I recommend leaving it in. If you were wondering about that behavior, chances are someone else will, later, as well.