This afternoon at Windy City Rails, Matt Polito of HashRocket gave a talk called “Why Cucumber is Still Relevant.” For those who haven’t used it, Cucumber is a gem used in conjunction with writing tests in a rails application that provides a domain-specific language for describing and documenting what the application is supposed to do.
He brought up this article by Martin Fowler, which poses a question:
Will DSLs allow business people to write software rules without involving programmers?
He ends up answering this in the negative, but instead identifies the value of making software business-readable rather than business-writable.
The programmer and the businessperson often come from different worlds, with different vernaculars. Cucumber, Matt argued, could serve as a bridge between the two worlds and help these two types of people communicate with one another.
Imperative vs. Declarative:
Imperative language explains a situation, while declarative language removes the extraneous information and just says what happened. Example: “I picked up the remote and pointed it at the screen and clicked a button, and something came up on the screen” vs. “I wanted to give a presentation, so I turned on the projector.”
The imperative example sounds an awful lot like the examples that programming instructors use in their first lessons about how to talk to computers. But businesspeople aren’t looking for that—they’re looking for the declarative version of the story. That’s what Cucumber offers through its DSL, expressing application tests something like this:
Here’s the crux of the Cucumber DSL:
and Matt offered a few examples of well-written cucumber tests, including the above pictured.
Matt also went over some best practices: establishing an understanding of what the business is trying to do, using @tagging in Cucumber to keep things clear, ditching feature metadata in favor of writing data into the test, and grouping together your givens, whens, and thens (in between which you can use ands and buts) in Cucumber code.
For more on writing good Cucumber tests, see Cucumber’s refreshingly cute-looking and example-laden documentation.