Chess TDD 44: Starting the Climb toward En Passant

En passant is going to be a fairly complicated thing to calculate, given the way I’ve implemented this thing so far.  And, true to form, I only got a very thin slice going in this episode.  Still, it was measurable progress and it’s good that I was able to slice thinly.

What I accomplish in this clip:

• Fixed a mistake in one of my tests that a viewer pointed out.
• Got the first en passant test passing.

Here are some lessons to take away:

• As always, peer review is king.
• Finding a way to carve thin slices off of large problems is an art form and so important.  Without this, it’s easy to be overwhelmed by difficult problems.
• When you’re writing a test and you see an unexpected behavior from production code, stop and clarify your understanding.  You don’t want to procrastinate with that.
• Edge cases account for a lot of complexity in design, which makes it doubly important to have a comprehensive regression test suite.
• Revisiting a design is really hard without automated tests to cover what you’re doing.  This tends to cause designs to calcify in untested codebases, even to the point of avoiding the addition of new functionality that users want.

Chess TDD 43: Pawns Good to Go

This episode was a lot of fun because all of the cards just kind of fell into place and I got the pawn done (with the exception of en passant). I had thought finishing up the pawn was going to take a number of episodes, but then there was a flurry of win. I’ll take it!

What I accomplish in this clip:

• Finished up the implementation of black pawn movement.
• Pretty well set with acceptance tests for pawn.

Here are some lessons to take away:

• Be on the lookout in your code for overly complicated boolean conditions; always look to simplify.
• If you can avoid creating more levels of inheritance and that sort of indirection, you should.  That sort of thing can be a helpful tool, but you pay a price in complexity.

Chess TDD 42: Finishing up White Pawn Movement

In this episode, fresh off the victory of getting pawn movement right for the white pawns, I start on the black ones by essentially reversing their movement.

What I accomplish in this clip:

• Got the first acceptance test passing for black pawn movement.

Here are some lessons to take away:

• Having one context per test class is a nice way to keep tests readable, focused, and organized.
• You’ll probably never stop making dumb mistakes, so it’s good to learn to have a sense of humor about it.
• Tests are very handy for confirming your understanding of the code base.  Feel free to tweak a value in a test just to see what will happen, and then put it back.
• Instead of hopping quickly into the debugger, see if you can try process of elimination things to narrow down where the problem is.
• If you find yourself in a class, typing the same conditional logic in every method, you have something that could probably be two classes.

Chess TDD 41: Finishing up White Pawn Movement

This post was the first of another three that I recorded together.  I wanted to tie up some loose ends and move on to implementing pawn movement for black, but I just wound up tying up loose ends.

On a meta note, I’m going on vacation out of the country for a week, so I may or may not be in a position to log in and push posts live this week. It may be a light week for DaedTech posts.

What I accomplish in this clip:

• Got IsNonCaptureAllowed working properly

Here are some lessons to take away:

• There’s nuance to when to drive your design/development with acceptance tests versus unit tests.  TDD is generally good when you want to iterate quickly to get a narrow implementation right.
• There’s no harm in extracting out a method from a test so that you can save yourself typing in the next test you’re writing.  (As long as you’re green while you do it)
• It’s not relevant to my series, per se, but it’s worth knowing what characterization tests are.
• Look out for the sunk cost fallacy with your own code.  The fact that you’ve pulled out and spent time creating a method doesn’t mean that the method is actually beneficial or valuable.
• Beware of iceberg classes.

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.