Chess TDD 13: Moving On

In the last bunch of installments of this series, I’ve implemented methods for pieces to determine where they can move on a board and/or done some refactoring.  But I’ve ridden that train as far as I can, now having implemented all of the pieces, so it’s time to shake things up a bit.  Another thing that makes this post different is that I’m going to try a new way of structuring my test classes.

The other day, in response to a comment, I made a post about test initialize methods and Steve Smith commented and suggested an approach he described in detail in this post on his blog.  The gist of the idea is dispensing with the old stand by of having a test class for class Foo called FooTest and instead having the name of the test class describe the context of the test, BDD-style.  I found this idea immediately appealing and decided I’d try it out in “some project to be determined,” but what’s the fun in that?  Once an idea settles in my head, it’s hard for me to shake it, so instead of doing it later, I’ll do it here, now, publicly.  Apologies in advance (I’m typing this part before recording the coding) if it results in a bit more floundering, but I think it might be fun for us all to learn together.  If nothing else, you’ll get to see how easy or difficult it is to adapt to this convention.

Anyway, here is what I accomplished in this clip:

  • Got started on complete move calculation implementation.
  • Defined the setup of complete board for a lot of tests.
  • Established a new pattern for constructing tests.

And here are some lessons to take away.

  • When you are exposed to a new practice or way of doing things, there’s no time like the present.  While it may not always be practical to ram the new stuff into some time sensitive project, experiment and try it out to see how you like it.  Trying out different techniques keeps you sharp and helps you avoid falling into a rut.
  • When you haven’t looked at code in a long time, it’s easy to lose track of internal implementation of classes.  One of the real perks of TDD and having a test suite is that it’s easy to poke and experiment to see what’s going on without fear that you’re going to break something.
  • If kept concise and focused, a bit of yak-shaving in your implementations can be pretty productive.  Always be looking to improve on your code’s readability, elegance, and efficiency if you can.
  • It’s important to keep your test suite as communicative and descriptive as possible, and you should always be looking for ways to help you toward that end.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1679()

  • John Pazniokas

    “… when the TDD’s over… and I start writing initial integration and edge-case-type tests…”

    Any recommendations on resources in THAT arena? Y… y’know, just in case any of your regulars have somehow managed to be almost-10-year vets without a single minute of automated testing, anywhere in their careers. It’s highly hypothetical, of course, that such a thing could happen…

    (Thanks again for this series.)

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

    Recommendations in terms of what? Like, which frameworks and tools to use? Or more like how to write those kinds of tests?

    (I could conceivably do a post on this, describing how I tend to approach these sorts of tests)

  • Tim Sirmovics

    Have you considered something like Trello for managing your TODO’s? If only for the sake of being able to move items around easier it would save the constant reformatting in Excel.

  • John Pazniokas

    Sorry, disappeared for a bit.

    I meant the latter.

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

    No worries. I’ll add a draft to address this. :)

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

    I use Trello daily, but I’ve always used it for tasks a little less granular. I have a Trello board that’s actually called “Daily” and the kind of tasks I put on it are “Record code for next TDD video.”

    I think what’s steered me away from the kind of usage that you mention is something you don’t necessarily see here, which is that there are times that I use the nature of a spreadsheet to define different columns on the fly or keep other “sub” or “meta” lists inline. Bear in mind, I don’t think any of this is really a particular barrier to using Trello — I’m just sort of mulling my own slight aversion to it for this use case.

    You’re not the first person to ask me that, though. So, maybe I ought to try it out and see how I like it. :)