Week 1, Friday

March 27, 2009 at 5:28 pm (Java, Week 1) (, , , , , )

I spent some time last night experimenting with Swing and was able to get the Tic-Tac-Toe grid set up, with some listeners on the squares. Then this morning I wired up the GUI to my existing Java Code. I only had to make one major change, which was getting rid of the Dependency Inversion Principle violation I had in my display code. I just turned that into an abstract class and moved the existing, console-based code into a subclass, and then also derived a GUI display class from the abstract class.

That part was simple, but I really did a lot of monkey-hacking today to get the GUI working properly together with the existing game code. I think part of the problem was that I never really stopped the “spiking” I did last night to learn how to use Swing a little bit. I just kept right on trucking (in implementation code, without tests) until I had a working game. So I need to go back and retrofit some tests to most of the code I’ve written today, which I’m sure will mean rewriting some things. My mom got me Michael Feathers’ Working Effectively With Legacy Code for my birthday, so I may dig into that some to give me some ideas. My understanding is that the book describes legacy code as any code not under test, so I wrote a bunch of legacy code today [frown].

On a brighter note, I’m going to be working with one of the craftsmen on an internal project, most likely using Rails, so at least I’ll be familiar with the language for this one. I’m glad I’ll have a compelling reason to learn RSpec, and probably Cucumber and Selenium as well. These are the kinds of things that motivated me to want to work at 8th Light in the first place. As I told one of the craftsmen when I interviewed, it seems like all of the big names in the Ruby world use TDD/BDD, so I really was looking forward to writing code that way.

I took my first crack at estimating (our initial iteration meeting for the project was today), and only time will tell if I was being too optimistic or not. I certainly don’t think we’ll have too little to do, but as I said in a previous post, I think I’ll get better at estimating as I do it more often and measure actual velocity (stories completed per iteration) against estimates.

Since it’s the end of my first week here, I’ll just close with a general thought on TDD: it isn’t faster to write your first few lines of code in a new project. But if you have tests for those lines, then you know they work. The tests allow you to forget about them, and still be able to change other parts of the eventual system without fear of breaking old stuff. Because it’s got a test suite that you run and see that of the system’s requirements that you have encoded in tests, you’re passing. I’m looking forward to making this a habit and really having TDD become my default coding behavior.

Advertisements

6 Comments

  1. Mike Wilson said,

    Here’s a challenge: Take the working code you’ve got and put it aside.

    Create a new project, set it up with JUnit, etc.

    And redo the thing from scratch all TDDish.

    It’ll take less time and you’ll end up with less (implementation) code than you think.

  2. trptcolin said,

    Thanks for the comment, Mike. Just to clarify, most of the code was developed using TDD/JUnit – just not the GUI classes. But yeah, I think you’re right that I’d be better off doing it that way than trying to retrofit tests…

  3. Mike Wilson said,

    Cool, then you’re way ahead of the game.

    Retrofitting tests is far from a useless approach šŸ˜‰ But so much of the benefit I get out of TDD is “Wait…. I don’t need ANY of that!”

    And I think that by retrofitting, you lose a lot of that opportunity.

    That said, GUI code is tough. Though I had the very good fortune to sit down with Mike Feathers for the better part of a day (a couple years ago now) and he worked me through a lot of it. The amount you can get done by passing in fake graphic contexts and null window handles is really quite impressive.

    But it IS the point where true fine-grained unit testing runs into some difficulty.

  4. Eric said,

    Hey Colin,

    I just watched Jim Weirich retrofit tests by doing Comment Driven Development. Comment out the code, then write a tiny first test. Uncomment the needed code to make it pass. Repeat until all code is uncommented (or you can delete code).

  5. Joakim Holm said,

    Hi Colin! Your mom has got to be the, hands down, best and most caring mom in the world! What a wonderful gift. (Apart from my own mom, of course). šŸ˜‰

  6. trptcolin said,

    Eric – OK, yeah, I was completely stuck for a long time this morning looking at redoing it TDD-style, but when I have the commented-out implementation (albeit a messy one) to guide me along, I at least have some sort of road map. I definitely need to work on learning how to formulate what to test first (and scoping things down so that they’re testable).

    Joakim- Thanks, she’s great! She also got me Pete McBreen’s Software Craftsmanship book (those were the top two priorities on my Amazon Wish List), which I’ve already been enjoying.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: