Last weekend I gave a talk on Test-Driven Development at the Fall 2009 CMAP Code Camp. Since this was a .NET event (and I'm a Ruby guy), I took a look at some previous talks I had given on the topic to focus on why someone might want to use a Test-Driven approach when developing software. It didn't hurt that there had been a lot of debate recently on the value of both unit testing and a test-first software development approach. The first part of my presentation focused on the benefits:

For the second portion of my talk, I did about 45 minutes of live coding (in Ruby) to demonstrate the process I go through when using tests to drive the code I write. During that time, we built a small working wrapper to the TwitterCounter API from the ground up. There was some good discussion afterwards about removing the remaining duplication and how best to evolve the design to better model the interaction with the API.

It was good to get in front of a different audience to talk about the value of testing as a design tool. Thanks to Chris Steen for the invitation and the rest of the CMAP group for organizing a great conference.

Today, Mark and I were talking about some of the open source projects we've been working on. During our conversation, he mentioned how David's recent post about using Autotest on OSX was the catalyst for him to start using it on his projects. I decided that I would do the same, so I went about using it on a Ruby gem that I'm developing.

From the original post, using it on Rails is pretty straightforward, but getting it to work on a vanilla Ruby project requires a bit of tweaking. There's some outdated information out there, but I was able to find a solution that worked for me. My resulting .autotest file:

require 'autotest/growl'
require 'autotest/fsevent'

Autotest.add_hook :initialize do |at|
  at.clear_mappings

  at.add_mapping %r%/^lib/(.*).rb$% do |_, m|
    possible = File.basename(m[1])
    files_matching %r%^test/.*(#{possible}_test|test_#{possible}).rb$%
  end

  at.add_mapping(%r%^test/.*.rb$%) {|filename, _| filename }
end

With that patch in place, I get the results I want.

Like any good Ruby developer working on a fresh bit of code, you eagerly start setting up to run your first test and get hit with this in TextMate:

`blank_slate_method_added': stack level too deep (SystemStackError)

Ouch. Screeching halt. The root cause for this comes from a conflict between TextMate's version of Builder and the system-installed version. There are a couple solutions floating out there - either remove the TextMate-bundled version entirely or drop this in your test file:

$:.reject! { |e| e.include? 'TextMate' }

I prefer this method as it doesn't have any noticeable side effects anywhere I've used it. This appears to be the official solution to date.

Do it!

class ApplicationControllerTest < ActiveSupport::TestCase
  context "An instance of ApplicationController" do

    setup { @controller = ApplicationController.new }

    should "return nil when there is no :user_id in session" do
      @controller.stubs(:session).returns({})
      assert_nil @controller.current_user
    end

    should "retrieve the current user when there is a :user_id in session" do
      user = Factory(:user)
      @controller.stubs(:session).returns({:user_id => user.id})

      assert_equal user, @controller.current_user
    end

    should "return nil when the :user_id in session can't be found in the database" do
      @controller.stubs(:session).returns(:user_id => 1)

      assert_nil @controller.current_user
    end

  end
end