Introducing Coulda - Evolutionary Behavior Driven Development with Ruby

It is often the case, a new piece of software is developed by someone who needed to fill a void left by an existing product. Software evolves from tools we use which don't exactly meet our needs, this is the case with a new Behavior Driven Development (BDD) tool called Coulda, developed by Evan Light.

Coulda, from its announcement,  is described as:

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 for re-use.

We had an opportunity to catch up with Evan to learn a bit more about Coulda. Since Coulda is so new, it was natural to get the developer's definition of Coulda:

Coulda is a Ruby internal domain specific language (DSL) for defining acceptance tests using Test::Unit.

BDD tools are not entirely new and certainly not to Ruby developers who utilize tools such as RSpec and Cucumber to write specs and stories. Tools that often are early to market lead to a new generation of tools. When asked what inspired the creation of Coulda, Evan explained:

Regarding Coulda's implementation, I mention Cucumber, Shoulda, and Thor in the README. Also, Jeremy McAnally's Context, Pending (Coulda uses Pending, actually), Stumpy, and Matchy were another source of inspiration. Jeremy intentionally designed several orthogonal testing libraries that could be integrated individually or together into Test::Unit. I'm very fond of that approach: building small targeted tools to solve specific problems. Rich Kilmer's closing keynote address as Lone Star Ruby Conference reminded me of the power and expressiveness of internal DSLs. Finally, a dinner chat with Andrea Wright reminded me to stop whining about what bothers me and just fix it. ;-)

However, the motivation behind writing Coulda is a bit more verbose.

I've used RSpec Plain Text Stories and Cucumber. I like the idea behind them--that is, expressing test preconditions in one type of code block ("Given"), events in another ("When"), and expectations in another ("Then"). I was put off that Cucumber forced me to map "plain text" to regular expressions--and particularly that Cucumber forced me to have those regular expressions in a separate file.

I'm of the mind that more physical (files) and logical (test descriptions and examples, in this case) units results in more complexity. I prefer to decide for myself when I will break up physical and logical units. Cucumber mandates that it will be thus: Gherkin in one file, test "steps" in at least one other file. When asked whether a particular best practice is true, most experienced programmers respond with, "It depends". With Coulda, I decide when I want to split the test descriptions from the test steps as the test descriptions and tests are just blocks. Coulda let's test complexity increase when and how I see fit.

In addition, Gherkin, (the pseudo-English DSL that devs/users write to drive Cucumber) maps to code via a sort of "call by regular expression". It is important to realize that this pseudo-English is, in fact, code. However, it is code written in a non-Turing Complete language. Given that, what's wrong with potentially giving users (or at least ourselves, the developers), access to a Turing Complete language when we write our acceptance tests? I can't speak for other developers but I write my own acceptance tests and often consult stakeholders about the acceptance test descriptions. However, if giving the reigns over to the user is desirable, we can teach users to write a simple internal DSL without teaching them Ruby just as easily we can teach them an external DSL.

Cucumber, developed by Aslak Hellesoy, is a tool (DSL) which allows application behavior to be expression in plain text. On the idea that Coulda is intended to be a replacement for Cucumber:

I see it as an alternative to Cucumber and not a replacement.

As some have rightly pointed out, Coulda is similar to RSpec Story Runner. Until Coulda, there has not been a similar tool for writing BDD acceptance tests (see http://dannorth.net/introducing-bdd) specifically for Test::Unit.  Because I tend to write my unit tests in Shoulda, I wanted something with the expressiveness of Cucumber but without the additional abstraction but that also runs atop Test::Unit as T::U has become something of a habit for me.

Coulda is a young project, influenced by Cucumber, which initially removes some of the more terse aspects of Cucumber implementation but beyond that, we wanted to know the goals of the project:

Honestly? To have the option to use Coulda when I work with a client/organization instead of being mandated to use Cucumber. That's why I wrote it!

Technically speaking, my goals are modest. Apart from any bug fixes, I intend to provide marshaling from Coulda descriptions to plain text such that:

Feature "My feature" do
in_order_to "accomplish a goal"
as_a "dude"
i_want_to "do something"

Scenario "Where I show how serialization might work"
   Given "a Coulda Feature" do
     ...
   end

   When "I run a rake task that marshals the object model to plain text" do
     ...
   end

   Then "I get plain text output that reads similarly to Gherkin" do
     ...
   end
end
end

Can be output as something like:

Feature: My feature
  In order to accomplish a goal
  As a dude
  I want to do something

  Scenario: Where I show how serialization might work
    Given a Coulda Feature
    When I run a rake task that marshals the object model to plain text
    Then I get plain text output that reads similarly to Gherkin

Other than the above, and Rails support (Features are Test::Unit::TestCases at the moment), I don't see any additional features on the horizon.  One of the key goals with Coulda is to remain small and simple.

For example, at the moment, I don't have any plans to emulate Cucumber's FIT-like tables.  In my mind, those can be satisfied with a "Given" block that uses factories using your factory implementation of choice--which is entirely orthogonal to Coulda.

Any new, open-source project, can use help from contributors.  The subject of contributions and documentation indicates there are opportunities to help out and shape the project, Evan says:

The RDoc is quite nonexistent at this point. ;-) Any volunteers?

I have a small sample file on the github repo (note to self: put it in the gem) under examples/sample.rb--although it is currently embedded in the README.rdoc.  It's executable by Coulda.

In all seriousness, though, the API is simple. It's made up of "Feature", "Scenario", "Given", "When", "Then", "Feature#in_order_to", "Feature#as_a", and "Feature#i_want_to". That's pretty much it. I hope to continue to keep it small.

Coulda is evolving and would benefit from additional contributors.  More information on Coulda can be found on the Github project page or on Evan's blog.