DaedTech

Stories about Software

By

Chess TDD 46: En Passant Expiration Date

This installment of Chess TDD was another episode focused on en passant.  It’s been a while since I was in this code base.  I’d been on the road a lot and without my main development/recording rig.  But now I’m back and was able to take the opportunity to record a little Chess TDD ahead of my wedding next week.  This episode went pretty smoothly.  I cleaned up a method from last time that had become unwieldy and then got the next acceptance test to pass without any flailing.  Not bad for so much time between episodes!

What I accomplish in this clip:

  • Refactored the Board.MovePiece method away from mounting ickiness.
  • Implemented functionality to prevent en passant from lasting beyond one turn.

Here are some lessons to take away:

  • When extracting methods during a refactor, if you have a hard time giving the new method a coherent name, it might be a sign that you’ve selected non-cohesive functionality to extract.
  • Spend a few extra brain cycles contemplating the names that you give things.  This investment will pay off because it’s easier to give things good names when their functionality is fresh in your mind.
  • If you start to have code that no longer seems to belong in a class, make sure you’re keeping that visible to yourself as you go so that you can have a nice cue for refactoring.
  • Take care to keep communication between methods and classes at an appropriate level of abstraction.  Make sure they’re communicating in obvious domain concepts.

By

Chess TDD 45: Onward with En Passant

This episode followed right on the heels of Chess TDD 44, in terms of the coding, and was basically a session extending that episode.  It wasn’t always pretty, but I made more progress on solving this edge case.  I’m in the midst of a pretty brutal stretch of travel, and then my wedding and honeymoon are coming up in early September, so I don’t know how many more episodes I can promise in the near future.  I’m home in about 2 weeks, so hopefully I’ll get a few in then.  Stay tuned!

What I accomplish in this clip:

  • Made the implementation of en passant sophisticated enough that a pawn can be made aware of an en passant target.
  • Got black capture of white pawn en passant working for moves to the right and left, both.

Here are some lessons to take away:

  • Never forget that if you have a failing test you can’t figure out, it’s always possible that you didn’t write the test well.
  • It’s okay to try changing pluses to minuses or tweaking off by one situations to get a test green, as long as you go back and understand what worked and why afterward.
  • It’s often the dumbest mistakes you make that take the most time to track down and are hardest to spot.

By

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.

By

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.

By

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.