Using Cucumber and Perl to define test cases in natural language
The Cucumber test framework helps developers and product departments jointly formulate test cases, not as program code, but in plain English. The initially skeptical Perlmeister has acquired a taste for this.
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 , 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 . 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
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.
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).
Listing 1  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
01 Feature: Simple tests of Yahoo::FinanceQuote 02 As a developer using Yahoo::FinanceQuote 03 I want to retrieve stock quotes 04 05 Background: 06 Given a usable Finance::YahooQuote class 07 08 Scenario: Retrieve Facebook 09 When retrieving the quote for ticker symbol "FB" 10 Then the numeric value is greater than 10
Keywords ending with a colon (
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.
Buy this article as PDF
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?
The new Torus distributed storage system is available under an open source license on GitHub
Juries decides Google’s use of Java APIs Was Fair Use
But if you are not using the latest Linux kernel, your system is insecure.
Home routers will give room for custom firmware but still comply with FCC rules