UPDATE: A few years after writing this I concluded that things like Cucumber introduce unnecessary overhead (see here).
I’ve been experimenting with behaviour driven development (BDD) using Cucumber lately. The idea is that you write (formalised) specs which describe the behaviour of your system, and they can also be executed as tests. E.g. I have this in my tests:
Scenario: Transcriber tries to start a transcription session when there are no calls Given I log in as a normal user And there is no work waiting When I follow "Start processing" Then I should see "There is nothing to process"
You could write the same thing in Ruby, e.g. using RSpec (a test library), and with appropriate helper methods written, the same test would be something like:
it "should inform the user when there is no work available" do login() delete_waiting_work() click_link "Start processing" page.should have_content "There is no work available" end
It looks quite similar for this example, however I find that using Cucumber (i.e. the original example) has advantages:
I’m sure some of this could be achieved with RSpec or another test library but it would require more discipline. With Cucumber, you can’t really slip into lower-level code in your test. And by the way, I still write some unit tests using RSpec, but they are limited to testing out particular functions.
The key thing, I think, is not so much the syntax but the fact that this approach results in tests which are focused on the behaviour of the system as seen by the user, at a higher level than classes or even individual components.