Stories about Software


TDD Chess Game Part 6: Starting with More Pieces

I recorded this clip at a home, where I have a pretty old dual core processor that’s really starting to show its age when I have the video capture software running alongside VS2013 with all of my plugins. So, if you see the recording looking a little choppy in places, it’s because I edited out some places where I finished writing a test and was just drumming my fingers waiting for the test to go green or something. No need to show you completely dead time. Note to self — probably time for a new machine here soon.

Here’s what I accomplish in this clip:

  • Pretty up Rook.GetMovesFrom() a bit with Linq via refactoring.
  • Added Bishop class.
  • Implemented Bishop.GetMovesFrom()

Here are some lessons to take away:

  • You can write a test that’s green from the get-go if you want another data point prior to a refactoring.  Strict TDD says you need a failing test before you modify production code, but you can write green tests to your heart’s content.
  • Sometimes inheriting from a base class or implementing an interface is the quickest way to get from non-compiling because of an undefined method to having that method defined.
  • Just stubbing out a test method doesn’t constitute a failing test.  As long as everything is green, refactoring is fine.
  • I personally find that there are occasions when extracting a method or defining a common method is actually the simplest way to get something to pass.  So, even though that seems really like a refactoring, it can be your simplest path to get a red test green because it saves re-coding the same thing repetitively.
  • It’s perfectly fine to leave a working, but ugly, method and come back the next day/session to refactor.  Often times a much more elegant implementation will hit you in the shower or on the drive to your office, and you’ll make short of cleaning up the method when you have this fresh perspective.

And, the video:

  • Anders Strömberg

    Excellent and enjoyable as always. I’m looking forward to your next post on the TDD subject.

  • bonder

    how about an offset value type like new Offset { x = 1, y = 1 } and then pass it to startingLocation?

    • That’s interesting — are you envisioning a method on BoardCoordinate that takes an Offset argument and returns a different BoardCoordinate? That does seem like an appealing design.

  • sten

    Very good videos! I like them! One question:

    Why not @~20:00 just remove all non valid coordinates after the loop, just like: moves.RemoveAll(m => !m.IsValidCoordinateForBoardSize(boardSize)); ??

    Is that too ugly?

    • I don’t know that there’s anything wrong with the approach, per se — just that it’s not my style. (Also, keep in mind it’s been a while since I did this coding, so I don’t remember exactly what was going through my head). Generally speaking in C#, I’ll have a construct like List only if I can’t get by with declarative Linq statements.

      Adding things to and removing things from lists is a much more imperative style of programming (declarative is like SQL — you specify what you want, not how to go about getting it). I generally gravitate toward doing as little “how” programming as possible. The reason I provide all of this background is because the concept of building a list and then taking things out of it wouldn’t really occur to me. I’d want to refine how I was building the list over the course of time until I was building exactly the right list by specifying the criteria for being in the list.

      But *ALL* of that is just my personal preference. There’s nothing wrong with imperative programming — it’s just a matter of tradeoffs. And, glad you like the videos, by the way. Thanks!

      • sten

        Thanks for the reply! Your train of thought led to a better implementation (later videos). I probably would be stuck at a more imperative implementation