Why Coulda?

Behaviour Driven Development (or good Test Driven Development practices) promote communication. Cucumber excels at communicating in pseudo-English via it's Gherkin external ("plain text") DSL.

However, Gherkin makes more work for the developer. Cucumber abstracts away the nuts and bolts of your tests. Yes, abstraction can be a good thing but Cucumber gives you no choice in the matter. It hides code blocks behind a "call by regular expression" invocation mechanism instead of making them readily available in the acceptance test description.

For some of us, this is too much abstraction and a code smell.

Coulda lets you write as much logic beside your specs as you want... or not. Have it your way.

What makes Coulda different?

Test::Unit

Coulda is built atop Test::Unit: that's "Test::Unit" in Ruby 1.8.6 but also "MiniUnit" in Ruby 1.9.x. There are already a bevvy of tools out there that are either testing framework agnostic or are designed specifically to work with Test::Unit.

Because T::U is a part of the Ruby distribution, if you have Ruby, Coulda will work for you right out of the box.

Smaller is better

I far prefer less code whenever reasonably possible. I find that many frameworks are simply too large for my puny brain! The learning curve intrinsic in thousands of lines of code is too much to bear.

So Coulda is tiny.

As of Coulda 0.3.0, it stands at under 250 lines of code. This makes it easier for you to pop the hood, look at the code, understand what's going on, and to move on smartly from there.

Does exactly two things

Coulda executes its internal DSL as Test::Unit tests. Coulda also marshals itself to plain text. Ok, so Coulda doesn't do *one* thing. Plain text marshalling seemed to valuable to pass up!

And that's all! Coulda will not be modified to provide additional orthogonal features.

If you want support for feature X, you won't find it in Coulda! If X doesn't exist in a gem that supports T::U, Please Do Investigate (PDI).