Using Cucumber and Perl to define test cases in natural language
Scenarios Still Without Actions
Once Cucumber is installed (see the "Installation" section), impatient developers can launch the test suite on a trial flight. To do so, you need to call the cucumber
program in the directory above the features
directory, in which the basic.feature
file shown in Listing 1 resides.
Of course, Cucumber has at this time no idea what actions it needs to perform based on the feature description, because the step definitions are still missing. However, it tries to help out by sketching in some Ruby code, as shown in Figure 1.
Each text entry after Given
, When
, or Then
describes a scenario. Interestingly, Cucumber treats these keywords in the same way and only uses the assigned step definition. The different designations are only used to formulate the requirements understandably for the user.
Perl Without Gloss
The Perl implementation, with the aid of the CPAN Test::BDD::Cucumber [4] module, lacks a bit of the elegance of its role model but gets the job done. To start the test suite, the Perl programmer does not call cucumber
as in the original Ruby version; instead, it calls a script named pherkin
, which is included with the module and probably a synthesis of "Perl" and "gherkin." The output in Figure 2 uses gray text for nonfunctioning scenarios to make perfectly clear which step definitions are missing.
Listing 2 shows the step definition, which snaps up the text after the Given
expression in the background description. The file must have an extension of .pl
and reside in a directory called step_definitions
below features
.
Listing 2
basic_steps.pl – Definition 1
The regular expression squashed between Given qr/
and /
in line 6 searches for a string (a usable <[...]> class
) in all scenarios of the feature. In case of a match, the class name grouped by the brackets in (\S+)
lies in the $1
variable, and use_ok()
checks in line 7 whether the class can be loaded on the system using use Yahoo::FinanceQuote
.
The auxiliary function use_ok()
comes courtesy of the standard Test::More module. In typical Perl TAP format style, it outputs ok 1 if all goes well, and not ok 1 if an error occurs. The pherkin
tool understands this format and highlights the feature text in green or red accordingly.
Figure 3 shows that the background statement executed before the actual scenario is now highlighted in green, whereas the two scenarios that follow – When [...]
and Then [...]
– are still gray, or undefined.
Listing 3 delivers the rest of the step definitions in order to fully process the feature file in Listing 1. The pherkin
script imports Given
, Then
, And
, and other commands before calling the step definitions; the user does not need to include extra modules for this. Note that the two steps in the Retrieve Facebook
scenario depend on each other because the first step retrieves the share price from the server, and the second compares the numeric value with a preset in the scenario text.
Listing 3
basic_steps.pl – Definition 2
An Exchange with Context
The two steps communicate with one another via a context that pherkin
provides in the $c
variable if – as in line 5 of the steps definition in Listing 3 – the Method::Signatures module is loaded and the function to be called is declared using func($c) {}
(instead of sub{}
as shown in Listing 2). The method stash()
retrieves a reference to a memory area, which provides space for data generated in one step and needed in another under the scenario
key.
In Listing 3, the When
step stores the share price retrieved from the Yahoo server by the getonequote()
function of the Finance::YahooQuote module below the context's quote
key. The Then
step picks it up again from this location in line 24. The ok()
function from Test::More checks in line 15 whether a share price has arrived, and in line 24 whether it is greater than the value set in the text.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)