Stories about Software


Chess TDD 15

Prompted by comments from a few people, I’ve decided to see if I like using Trello for keeping track of the TODOs instead of Excel. Also, learning from past feedback, I’ve defaulted Trello to being really big when recording so everything is legible, and I copied everything over from Excel. Hopefully I like it as I go, but please let me know if it’s more pleasing to view as compared with the Excel spreadsheet, if it matters to you one way or the other.

Also, a meta-note. I apologize for the time between posts in the series and for the lack of posting in general, but I’ve been traveling nonstop and am pretty much living out of hotels, meaning my life is one of 3G-ish wifi and sub-optimal setups. Luckily, I’m driving everywhere and lugging my boom mic, desktop and monitors with me so I can still record in the hotel. 🙂

Here’s what I accomplish in this clip:

  • Make the “blocked” algorithm for horizontal/vertical less dumb.
  • Start the implementation for “blocked” diagonal.
  • Inadvertently create a potential solution for the problem of knight’s oddball movement.

Here are lessons to take away:

  • Even little things matter when it comes to readability.  For instance, at 0:40 I noticed that my test class name ended in should but the methods started with “returns.”  So, I took the time to fix this.  My advice is to get in the habit of avoiding sloppiness and inattention to detail at any level of code.
  • Bear in mind that changing prod code is fine while green in TDD, provided you’re not looking to introduce new behaviors.  It’s a refactoring if your goal is continue satisfying existing test cases in a different way.
  • A little before 10:00, I refactored a bit of a test while red for the sake of readability.  I shouldn’t have.  My bad.  Lesson is, no matter how much TDD you do, sometimes you flub it.
  • Sometimes a great way to get things passing when the implementation is getting hairy is to tease out a conditional that only applies to your new case and do something obtuse.  Use with discretion because it can lead you into blind alleys and cause problems, but there are times when getting to green can provide an aha! moment.
  • You’ll notice I refactored to a different method signature, changed some stuff around, and then refactored back.  This kind of waffling is fine.  With TDD, you’ll get used to fearlessly refactoring and slinging stuff around until you settle on something you like (or at least thing is the least bad, for now).
  • Get it working ugly now, make it pretty later.  It’s sometimes amazing how an algorithm will suddenly make itself obvious after a bit of brute forcing and futzing around.

Newest Most Voted
Inline Feedbacks
View all comments

[…] Chess TDD 15 – Erik Dietrich continues his screen cast series on Test Driven Development creating a chess implementation. This post continues with the work on blocking pieces and looks at the implementation for the Knight which does not obey the same rules as other pieces. […]

Sunil Pandey
Sunil Pandey
9 years ago

Hi Erik,
I’ve downloaded and installed your

“MS Test Report Generator”,
But not sure, how to use it.
Can you please let me know how to use it?
Or mail me on “pandey.sunil88@hotmail.com”

Best Regards,

Erik Dietrich
Erik Dietrich
9 years ago
Reply to  Sunil Pandey

Hi Sunil,

Wow, it’s been a long time since I looked at that tool. 🙂 Here’s a link on my blog to the most recent post about it: https://daedtech.com/ms-test-report-generator-v1-1 And here’s the original link: https://daedtech.com/ms-test-report-generator

There are instructions up on SourceForge, and I can tell you that after three years, they’ll be more help than I will right now 🙂

Drew Hannay
9 years ago

There seems to be something missing between this video and the last one. I was able to catch my code up using Github, so it’s not a huge deal though.

Erik Dietrich
Erik Dietrich
9 years ago
Reply to  Drew Hannay

If memory serves, I haven’t always been completely diligent syncing the github commits with the videos. Apologies for that.