Testing failure

A common pattern in our apps is handling failure by notifying Hoptoad. A good example is hitting a third party web service, Twitter, from Thunder Thimble.

def fetch_tweets(search)
  search.fetch
rescue *(HTTP_ERRORS + Twitter::Search::ERRORS) => error
  HoptoadNotifier.notify(error)
  []
end

Hoptoad

We send rescued errors to Hoptoad, shielding our users from 500s with relevant copy.

Twitter gem

This code uses John Nunemaker’s Twitter gem. The Twitter gem nicely allows the separation of building a query (object initialization) and making the HTTP request (fetch method).

Isolating HTTP calls

So, somewhere else, we do heavy-duty query building. We can then isolate the HTTP request inside it’s own one-line method, and rescue an expected class of errors.

Aside from testing failure, this isolation makes our other tests easier. We can stub the fetch_tweets method and forget about the interface to the Twitter library.

Arrays of error types

HTTP_ERRORS comes from the Suspenders’ errors initializer and Twitter::Search::ERRORS is something custom that we’re experimenting with in a real-world app, Thunder Thimble, that we’ll merge upstream to the Twitter gem when we feel we’ve learned enough.

How then shall we test?

We use Joe Ferris’ branch of Mocha for its test spies. We hope this Mocha mailing list thread will lead to merging the branch into Mocha. Please comment there if you have an opinion.

Testing failure

*(HTTP_ERRORS + Twitter::Search::ERRORS).each do |error|
  should "notify hoptoad upon #{error} on fetch tweets" do
    brand  = Factory.build(:brand)
    search = stub('search')
    search.stubs(:fetch).raises(error.new(''))
    HoptoadNotifier.stubs(:notify)

    brand.fetch_tweets(search)

    assert_received(HoptoadNotifier, :notify) do |expects|
      expects.with(is_a(error))
    end
  end
end

This is a classic stub-and-spy test.

It uses the normal Four-Phase Test structure. The extra newlines separate the setup, exercise, and verification phases. The test is flat; it does not use a context block.

I’m happy with this approach. What do you think?

Step right up, win a $1,295 prize

Here at thoughtbot, we love a good contest.

It’s been too long since the last one, so here we go again. Now since we all kind of know each other, I’m sure we’ll all feel comfortable within the confines of the honor system.

Follow @thoughtbot

That’s it. All followers of the @thoughtbot Twitter account will be eligible to win a prize next week. We’ll pick a random winner for the following prizes.

• On Monday, winner gets a Widgetfinger account.
• On Tuesday, winner gets a Tadpole Hoptoad account.
  (4 projects, 4 users, Lighthouse integration)
• On Wednesday, winner gets a Toad Hoptoad account.
  (16 projects, 16 users, SSL, Lighthouse integration)
• On Thursday, winner gets a Bullfrog Hoptoad account.
  (32 projects, 32 users, SSL, Lighthouse integration)

Open source markets

Since Vegas has yet to release odds, we’ve created the Open Source prediction market to answer burning questions we have, such as:

Who will win a Ruby Heroes Award at RailsConf 2009?

I’ve got my money on James Golick, but Jason thinks he’s a long shot.

We’re also constantly faced with a decision about which open source project to use for certain tasks:

• Which RESTful controller? giraffesoft/resource_controller, ianwhite/resources_controller, or hcatlin/make_resourceful?
• Which REST client? jnunemaker/httparty or adamwiggins/rest-client?
• Which state machine? rubyist/aasm or pluginaweek/state_machine?

To make the markets measurable, we’re using github watchers as a proxy for “preferred open source project” and setting a date of RailsConf so people think relatively long-term.

When you’re atop the leaderboard at high noon EST on Friday, you win the big prize:

One FREE ticket to a thoughtbot training class,
a $1,295 value.

So trade early trade often at the Open Source prediction market, and tell your friends.