Chess TDD 47: En Passant in the Other Direction
It’s been a while since the last episode, due mainly to my wedding and honeymoon, but here I am, back in action. For some, there were a few audio glitches in the recording of this episode. I did just upgrade to Windows 10, so maybe my version of Camtasia isn’t playing nicely with or something. My apologies, but I think it’s just minorly annoying and not a problem for understanding. This episode is pretty straightforward. I performed a little bit of cleanup on naming and then finished up by implementing en passant in the other direction.
What I accomplish in this clip:
- Fixed some naming hangover from last episode.
- Got en passant working in the other direction: white pieces capturing black pieces.
Here are some lessons to take away:
- I’ve said it more times than I can count, but naming is so important. Spend extra time with it. Revisit it. Make your methods as readable as progress.
- When you’re test driving (or, at least, making sure to write a lot of automated tests), the kinds of refactorings that a lot of people promise to do ‘later’ and never do turn out to be a lot easier. You’re much more likely to deliver on promises to clean up later.
- If you have logic that you want to test and it’s 2, 3 or more calls deep in private methods, this is often a sign that you should extract a class and have two different public surface areas to test.
- If you can delete a line of code in your code base and no test goes red, you’ve failed at some point in your test driving. Either you’ve deleted a test that should exist or else you’ve added functionality to prod without having a failing test that requires that addition. It happens to the best of us, but understand that it’s a problem and either delete that code or add a test that makes it necessary.