coulda

As a former Java developer of many years, having witnessed abominations such as EJB 1.0, Spring (sorry, Java developers; I prefer my meta-languages Turing complete), etc., I have a keen sense for unnecessary abstraction.

As a BDD adherent, I was excited when Cucumber was released. I had used RSpec StoryRunner before and liked it a great deal. StoryRunner allowed me to see my problem domain at a higher level without fussing with code. Neat! And yet all was not well. StoryRunner was frustrating due to its lack of automation, requiring developers to implement their own adhoc frameworks for executing stories.

Cucumber solved the problem. Wonderful!

But as I used Cucumber, I found myself encountering cognitive resistance. Writing regexps to map Gherkin to code blocks just didn’t feel right. If you’ve read any of Malcolm Gladwell’s “Blink” then this should tell you something. The regexp-mapped blocks are in essence de facto methods invoked via “call by regexp”.

I spent a great deal of time at Lone Star Ruby Conference discussing my Cucumber woes with folks. For a while, I have preferred using shoulda for all levels of testing. Joseph Wilk pointed out to me how Cucumber provides one better in that it allows a spec/feature to explain why it was written (via the “In order to , As a , I want to ” statements). That resonated with me. I have occasionally looked back at a spec, that I or someone else wrote some months ago, and wondered just why that spec was written. But I could not get past my cognitive resistance when using Cucumber.

As whining about my problems only gets me so far in life (not very), I decided to do something about it. So, like most Rubyists out there who want a tool that they don’t have, I built it.

I wrote coulda.

coulda, as you can guess from the name, conceptually borrows from Cucumber and shoulda – with just a little bit of thor thrown in for good measure. coulda is a simple internal DSL for capturing the same information as Cucumber but without Gherkin; it’s Cucumber stripped to the bone and with less work for the consumer developer. The thor nod is because coulda uses plain ol’ method calls fore re-use.

require 'rubygems'
require 'coulda'
include Coulda

Feature "feature name" do
  in_order_to "foo"
  as_a "bar"
  i_want_to "blech"

  def something
  end

  def expectation
  end

  Scenario "pending scenario"

  Scenario "another scenario" do
    Given "a pending prereq"
    When "something happens" do
      something
    end
    Then "expect something else" do
      expectation
    end
  end

  Scenario "that is live" do
    Given "foo" do; end
    When "bar" do; end
    Then "blech" do; end
  end
end

coulda uses Test::Unit under the hood. It creates “test_*” methods from Scenarios using the Scenario’s block as the test implementation. Pretty simple really. If your Scenario doesn’t have a Given/When/Then or has them but one or more is missing a block, it treats the Scenario as “pending” (courtesy of Jeremy McAnally’s “pending” gem).

Perhaps most importantly, coulda is a good citizen. Other than adding a “Feature” method to Kernel, no monkey-patching occurs under the hood. It is only a few hundred lines of code. And it should, hypothetically, play nicely with whatever other testing tools that you choose to mix into it (i.e., rr, mocha, webrat, etc.).

I’m entirely open to fixes and contributions. Please, fork away!

For the future, I intend to add at least:

  • 1.9 support (already found a small hitch there; I wrote coulda aginst 1.8.6)
  • a rake task to marshal coulda descriptions into Gherkin-like plain text for communication purposes with your boss/customer/non-technical weenie du jour.

Update: 1.9 support added as of version 0.1.2

Posted by evan on Saturday, September 12, 2009

blog comments powered by Disqus