Want to stay on top? Ruby Weekly is a once-weekly e-mail newsletter covering the latest Ruby and Rails news.
     Feed Icon

Coulda: A Cucumber-like DSL for BDD

By Ric Roberts / September 14, 2009

cucumberEvan Light has recently pushed his Coulda project to Github - it's a test framework based on Test::Unit, inspired by Cucumber, Shoulda and Thor.

Coulda works like Cucumber in that it's a Domain Specific Language for capturing the behaviour expected by your code, as part of the Behavior Driven Develoment approach (BDD). Others have noted it's a little like the RSpec story runner.

Where Coulda differs is that instead of using Gherkin to convert your statements about the behavior to code using regular expressions, it uses standard method calls. This is less of a cognitive leap for the developer... with Coulda, you can test like you code.

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

To be honest, I'm not a big user of Cucumber, so I'm not able to give much of an intelligent commentary here - I suggest you read more about Coulda on Evan's blog. You can get the code on Github.

devver-icon.gifAlso.. Got a slow Test::Unit or RSpec suite? Run them up to three times faster on Devver's cloud! Setup is simple and requires no code changes. Sign up now!

Comments

  1. M. Scott Ford says:

    One of the big advantages of Cucumber's Gherkin language is that it can be read and written by *non-programmers*. Coulda looks great for a dev team that wants to throw BDD into the mix, but getting your customer or product owner to write the behavioral tests for you should be the ultimate goal.

  2. Kevin W. Gisi says:

    To be honest, this seems a step away from the huge benefit of Cucumber stories.

    Unlike unit and functional tests, the cucumber stories are end-user-friendly. You can come back to a client, show them the story, and have them walk through each step.

    As much as contexts and such are great for us developer types, Cucumber stories aren't the place for them.

  3. James Thompson says:

    While this is certainly a neat project I still prefer Cucumber's approach. This makes the feature scenarios less distinct and readable to a non-developer. It's not bad in that regards, but it introduces code where it might not belong in my estimation if you are using Cucumber feature's to get non-developers involved with defining test criteria.

  4. Jeremy says:

    Can I ask an honest question here?

    Who *actually* lets customers write their tests?

    I mean honestly, for real letting your customers go wild writing their own business logic tests. *Reading* I understand, but you can get readable output from coulda or even T::U with some of the libs. But I've never actually, in practice, seen anyone who lets their customer write their Cucumber tests. If you do, please blog about it, because I'm very curious as to how that works out.

  5. Christian Romney says:

    Given that so many people read this blog, I would humbly ask you do the community a huge service and remove the first line of your code sample. :)

  6. Sandro says:

    Christian, what are you talking about? The code sample is an example; it's client code not library code. Who cares if the consumer of Coulda uses rubygems or not?

  7. Casper says:

    The fact that a customer reads the test is not so important, but for him to be able to read and understand the tests is. It makes the developer write the tests at the consumer level and not at his own level of understanding of how the program should behave. The tests are the first consumer of the code and therefor should be more inline with a user than a developer mindset.

  8. Stefan says:

    Coulda doesn't seem to be a real alternative for Cucumber because of Cucumber's support of writing tests in prosa.

    @Jeremy:
    Cucumber can be used for discussing features of an application together with your customer. It's up to you if you do it;)

  9. andhapp says:

    @Christian - haha good one...

    @Jeremy - I do not think anyone commenting here meant customers...there are other business account managers who have no idea about how the system works and since they are dealing with the clients cucumber does give them a bit of confidence that the system might perform as it says in the features.

    I would still wish good luck to Evan on his work. Well done!!!

  10. Jeremy says:

    I'm not asking about reading and understanding, I'm talking about writing. You can get readable output from anything like this, but the whole "benefit" of Cucumber is that customers can write their own apparently. Which no one seems to actually do.

    So I'm confused how coulda is somehow worse than Cucumber simply because it can't do something you don't actually do...?

    I don't mean to be contrary; I'm just genuinely curious about it.

  11. Evan Light says:

    Once I've written the rake task for coulda that converts coulda code into plain text, then devs will always have a way to have a coulda product that can be communicated with customers.

    I am curious to hear @Jeremy's question answered: who let's their customers write acceptance tests? Do you really teach your customers to program in your Gherkin DSL? Because, really, it *is* "call-by-regexp", invoking blocks of code by regexp.

    If Rich Kilmer can teach bureaucrats in the US Govt to read (if not write) a very simple internal Ruby DSL, I believe that most customers can be taught the same just as easily as they can be taught to "code" in a domain-specific Gherkin.

  12. Aslak Hellesøy says:

    @Jeremy: "Which no one seems to actually do"

    You don't know that - you're just saying it.

    I know of several people who work on projects where the business writes Cucumber features. Some completely on their own - some with help from testers or developers.

  13. Aslak Hellesøy says:

    That said, Coulda is a very clean. On the abstraction level scale it sits right between Cucumber and RSpec/Shoulda/Test::Unit. I might even try it out myself for smaller projects - if I know no business people will ever get near.

  14. Ryan Bates says:

    I find Cucumber stories useful as a developer since it helps me put on the customer hat and not be caught up in the Ruby implementation. Typing in plain text forces me to focus on the external functionality rather than how it works internally.

  15. Evan Light says:

    @Ryan: There's virtually no difference between pending Coulda specs and pending Gherkin steps with exception to the inclusion of "do", "end", and the use of "in_order_to", "as_a", and "i_want_to" methods. Otherwise, you're just typing in Strings. It's when you go to implement your Givens/Whens/Thens that Coulda becomes a somewhat different beast.

  16. Steve Mohapi-Banks says:

    We develop plain text Cucumber stories with our business people and they show great aptitude at doing so. Over time we'll definitely move towards them owning those stories.

    However, for developers having I can see some benefit in Coulda and the fact it's all in one place rather than distributed between plain text and step definitions.

  17. Evan Light says:

    More information, include tutorials, a mailing list, and IRC channel may be found on this website: http://coulda.tiggerpalace.com

Other Posts to Enjoy

Twitter Mentions