I'm a practical thinker and a realist – a natural combination, I find. In regard to developer frameworks for non-programmers, however, this means that when a new software product claims to support development on the basis of mouse clicks or descriptive text instead of code, I tend to steer clear. Experience has shown that, although simple solutions can be created with natural-language means, these projects reach their limits as tasks grow increasingly complex. When this occurs, the developer may have to ditch the project and re-implement everything from scratch in a proper programming language.

Perlmeister Stands Corrected

A few years ago when I first heard about the Cucumber project [1], which describes test cases for software projects in natural language, I immediately suspected a retake of the familiar "you-don't-need-programming-skills" mantra. My reflex was to turn my back on Cucumber and steer toward things with more substance. But, it seems I was wrong, because the project has gained much popularity among serious developers in the meantime.

In the end, I revised my own opinion. The decisive factor was reading the book about the Cucumber project [2]. The 300-page book explores the functions of the toolset in detail and shows step by step how a useful test suite is created during a real-life software project.

Here's how it works: In addition to the natural language description of a test case, say, Fetch the Facebook stock quote from the server, Cucumber uses step definitions that use regular expressions to search the text and trigger actions that are encoded in a proper programming language. In this example, the step definition would jump to Fetch the … stock quote in the text, extract the Facebook parameter, and get ready to retrieve the price of Facebook shares from the server with a function from a web library.

Most of Cucumber's step definitions are written in Ruby, but the toolset also supports Java or .NET. Thanks to the CPAN module Test::BDD::Cucumber, there is even a more or less satisfactory Perl port that you can experiment with.

Good Etiquette

Cucumber does not just wrap monotonous test code in naturally formulated scenarios but generally promotes Behavior-Driven Development (BDD). This not only helps the programmer writing the test of a function before the actual implementation (Test-Driven Development, TDD), but it also specifies that the test ensures a desired behavior of the software externally (i.e., something that the product manager also understands).

With its structure, Cucumber encourages programming of both code and test code to meet the requirements for easily maintainable software. After all, if you use a cowboy coding method for your test cases, you should not be surprised that changes in the application require more work to fix the test suite than to write the actual project code.

Re-using step definitions in several scenarios actively prevents code duplication and thus installs safeguards against future maintenance problems. Cucumber also separates test preparation ("scaffolding") from execution. During the test run, this approach causes the suite to tear down and rebuild the test framework before each test case, which reliably prevents "leaky scenarios" (i.e., scenarios in which one test case impairs the next).

Friendly Helper

Listing 1 [3] shows a complete test description of a module for retrieving stock quotes. The file describes a "feature" (i.e., a required function of the system), which the developer will check with multiple test cases (scenarios). For Cucumber to recognize them as such, the file must reside in a directory by the name of features and have a suffix of .feature.

Keywords ending with a colon (Feature:, Background:, Scenario:) introduce the individual sections in the feature file; their content is indented two spaces. Cucumber checks the functions of a feature by running multiple independent scenarios.

In practice, each test case requires a few steps to initialize – typing this every time would break the rule "Do not repeat yourself!" The Background: section therefore defines actions that should take place before the start of each scenario. In my example, the programmer checks whether or not the CPAN Finance::YahooQuote module used for retrieving the share prices from the Yahoo server is installed and the script can thus create an instance of the class.