TDD Chess Game Part 8: Hail to the King

Today’s episode is one with a pretty directed focus. I’m actually typing this prior to doing the screen capture, but I know what I want to do ahead of time. I want to implement the King piece, and I have a relatively good idea how to do it.

Here’s what I accomplish in this clip:

  • Implement King with GetMovesFrom()

Here are some lessons to take away:

  • Sometimes you’ll go into a coding session with a discrete, obvious goal, and other times you’ll have to break a nebulous goal into discrete, obvious ones.  But you always want discrete, obvious ones if you can.
  • If you can save yourself using the mouse via being proficient with keyboard shortcuts, I’d definitely go this route.  The time savings amortize over lots of coding.
  • For “simplest thing” in TDD, it doesn’t always mean that you have to bang out a line of code.  Maybe you can pull an existing method to a common ancestor and use it, or instantiate and use some other object.
  • “Simplest thing” is kind of an art form geared toward your best productivity.  If you’re new to the process of TDD, you probably want to keep it really simple before you’re experienced enough to be discerning.  Once you’ve established it and gotten good at the basics, you can adjust to situational taste.  Perhaps sometimes you’re stuck and need to get really simple while, in other cases, you have a good grasp on what comes next and being obtuse would just be busy-word.  Practice and use your judgment.
  • If you’re using a continuous testing tool (and specifically C#), pay attention to coverage with IEnumerables.  It seems trivial, but it’s really better if you’re executing every line, even if it just means calling ToList() somewhere.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1639

  • Pingback: The Baeldung Weekly Review 25

  • Geoff Mazeroff

    I find it fascinating (maybe even motivational) to watch other people develop code. I think as developers we sometimes lose focus and only consider the finished work instead of the re-work and metamorphosis that happens as things come together (or fall apart). (Perhaps the process can be equated to sitting next to a writer and seeing how he moves concepts around, develops better phrasing, etc.)

    Although I’ve never met you, I can sense the effort and consideration put into these videos. Your style is an excellent blend of experience/mastery tempered with righting yourself when the path you followed didn’t work out. I appreciate you explaining *why* processes, techniques, language features, and tools work for you; many others preach at their listeners without leaving room for reflection.

    Thanks for making these materials available; the effort is certainly appreciated by this developer. :-)

  • bonder

    A hearty second of this thought. Really enjoying this series!

  • http://www.daedtech.com/blog Erik Dietrich

    I really appreciate the kind words and the feedback, and I’m glad you’re finding it helpful. It has struck me at times that you see source code everywhere — github/sourceforge/etc and not so much the process. Even source history only tells so much because it’s not like people check in every little change (or screwup). It’d be interesting if there were a lot more deals out there where you could observe others coding. Sort of like passive/asynchronous pairing.

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks! Glad you’re liking it.

  • John Pazniokas

    Another big thumbs-up. I’ve been keeping up with your blog outside of this series, but skipping this series until I have time to really sit down and focus on it. Just blew through them all. (Yes, with the last several in the reasonably early morning of a holiday. Shows where my mind is right now…)

    It’s tough for a text or a written blog series to really show TDD in its glory, because those media are a polished-final-version description of an in-process methodology. The way you’re doing this is a great resource. Thank you.

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks for the feedback, and I’m glad you’re finding value in the medium. A couple of years back, I did a series on the bowling game kata with TDD and I posted a *LOT* of code to try to do a granular, step by step how-to. But I remember thinking no matter how many steps I posted code for, it just wasn’t the same as pairing or a video. So it’s good to hear that this captures what posts with code snippets don’t.