Pair Programming Firsts

I had a great time pair programming last weekend. It was the first time I had done this in a formal, our-computers-are-connected-and-we're-typing-at-the-same-time kind of way. I've programmed with people at the same computer, collaborated with people on different computers in a casual throw-ideas-back-and-forth kind of way, and done the passing-the-laptop-around thing, as well. But, a lot of my development time has been alone. For instance, I had a job for six years where I not only worked alone, but I telecommuted. During this time I lived in Brooklyn, Austin, Denver and Chicago (though not all at the same time). This was great and terrible at once: I had wonderful freedoms and benefits (cross-country travel and NY salary with TX income tax rates, to name a few), but I missed having other developers to learn from and play with.

Read the rest of this post »

Hold the Candle, Read the Code

Maybe you inherit an application, as I have. With an old test suite: some tests, but not too many. Written in Test::Unit, not overly clear from the wording what they are doing. Reliant of fixtures with evocative yet ambiguous names: @full, and @empty. But they're there. You run them. They pass. 
def test_homepage_section
    assert !@empty.on_homepage?
    assert @full.on_homepage?
  end
Then one day, you're exploring some of the code covered by these tests in order to add a new feature to this particular corner of the site. Some code needs to be written, some needs to be refactored, all of it needs to be understood. It's the perfect time to port the tests to RSpec, as you've been doing little by little as time permits. Fixtures are replaced by Factories, underscored test names replaced by strings; and yet, as you get started, it's clear that whatever a particular test is asserting is simply not clear from reading it. Yes, '@full is on homepage', you say to yourself. But what exactly does that mean?

Read the rest of this post »

If you're not pending, flunk.

I've inherited a Rails project from a big design firm. My job is to stabilize it in its new environment, maintain it, and eventually grow and improve it. Today was a bit traumatic: I deleted 47 files from the project. These were unit tests and functional tests that were either completely empty, like so:

class ModelTest < ActiveSupport::TestCase
# crickets
end

Or functionally empty, a result of leaving scaffolding in place, like so:

class OtherModelTest < ActiveSupport::TestCase
# Replace this with your real tests.
def test_truth
assert true
end
end

Forty Seven Files.

The problem here is not only that much of the app is not tested (nor documented by well-written specs), but the presence of the 47 passing test files gives a false sense of security to anyone eyeballing the project before they realize that the coverage is in name only. Certainly there were many (ok, some) files with active tests in them (I'd say I pulled a little more than half the files from the project) but it left me a bit shell-shocked to realize not only how little was covered, but that this cruft had been passed back to the client.

Read the rest of this post »

Acts As Followed

I released my first Rails plugin today. Acts_as_followed allows you to set up "followships" between users and other resources in your domain. It's fairly simple as these things go, but it was an instance where I felt that encapsulating the logic would make this pattern easier to implement across many projects -- and an opportunity to become more familiar with writing a plugin. Naming-wise, acts_as_followship is a little dry; I actually prefer acts_as_celebrity_stalker, but didn't feel like changing all the names. Perhaps in the future.

Read the rest of this post »

Fixture Replacement with Factory Girl (Sorry :quentin)

I've been working with fixture replacement objects for quite some time in my Rails testing, so the concept and the ease-of-use isn't new. The solution I've been using is a home-grown one implemented by a former colleague in response to discussions at work about how best to replace our store of seed data and fixtures but still get objects that are initialized to a set of reasonable (i.e., valid) defaults with the option to override. It was a good solution for us at the time. That said, I've heard a lot of buzz about Factory Girl. Given that I was setting up testing in a new project last night, I took the opportunity to explore it.

Read the rest of this post »