Chess TDD 40: Diagonal Capture for Pawns
This post was the last of a series of 3 I recorded together, so it picks up right on the heels of episode 39 from a flow perspective. I initially tied up loose ends from the previous episode and then got the pawn’s diagonal capture in place, at least for the white pawns (acceptance tests for black pawns won’t go well right now). Fits and starts, but real progress nonetheless.
What I accomplish in this clip:
- Finished the TDD implementation for IsCaptureAllowed
- Implemented IsNonCaptureAllowed
- Finally gave pawn diagonal capture ability
Here are some lessons to take away:
- Always look to refactor test code when it comes to readability and eliminating duplication. These refactorings are not just for production code!
- There’s a sizable contingent of people that don’t like seeing the Assert call factored out of unit tests. Clearly a matter of personal preference, but you may get pushback in a shared code base.
- In methods, preserve a consistent level of abstraction. If you have complex two part conditional, don’t factor out one part and leave the other part — make them both conceptually similar.
- Clean, readable code will look at least vaguely familiar to domain experts, even if they aren’t programmers. They should see/read concepts that are familiar.
- Keeping the lines of code low in a class isn’t a first class or all-encompassing goal. A class can get ugly by having too many methods, even if all of those methods are small.