Coulda: A Cucumber-like DSL for BDD
Evan 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.
Also.. 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!
September 14, 2009 at 5:55 pm
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.
September 14, 2009 at 7:01 pm
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.
September 14, 2009 at 9:28 pm
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.
September 14, 2009 at 11:27 pm
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.
September 15, 2009 at 12:51 am
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. :)
September 15, 2009 at 5:40 am
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?
September 15, 2009 at 5:58 am
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.
September 15, 2009 at 7:13 am
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;)
September 15, 2009 at 10:16 am
@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!!!
September 15, 2009 at 6:05 pm
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.
September 15, 2009 at 6:08 pm
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.
September 15, 2009 at 6:13 pm
@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.
September 15, 2009 at 6:28 pm
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.
September 15, 2009 at 10:40 pm
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.
September 21, 2009 at 11:03 pm
@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.
September 27, 2009 at 8:05 am
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.
September 30, 2009 at 5:54 pm
More information, include tutorials, a mailing list, and IRC channel may be found on this website: http://coulda.tiggerpalace.com