Appendix A. Cucumber
In this appendix we will give a brief introduction to Cucumber. For a more in-depth introduction check The RSpec book [CAH+10], the Secret Ninja Cucumber Scrolls [dFAdF10], or the Cucumber website at http://cukes.info. Both books handle more advanced topics such as setup and teardown mechanisms and organization of your feature files.
Cucumber is a behavior-driven development (BDD) test automation tool. That means that you will need to describe your examples using the Given-When-Then format.
Cucumber is based upon Ruby. If you have Ruby installed, run the command gem install cucumber with administrator privileges, and wait for the installation to succeed. If the installation complains about missing dependencies, you may have to add the -y option to the gem command. In newer installations gem automatically derives the dependencies by default.
Feature Files
In order to get started, you need a feature file. A feature file describes the feature that you are about to implement in your application. A sample feature file consists of a feature line that names and describes the feature and one or several scenarios or scenario outlines. Each scenario or scenario outline consists of any number of Given-steps, one When-step, and one or multiple Then-steps.
The Given-steps might be left out. This is especially the case when you set up the system in a common set up inside the code, or if there is nothing special to get your application started. The When- and the Then-steps are mandatory in order to execute and test something in your application at all.
An example feature file is shown in Listing A.1.
Listing A.1. An example Cucumber feature file
1 Feature: Valet Parking feature
2 The parking lot calculator can calculate costs for Valet
Parking.
3
4 Scenario Outline: Calculate Valet Parking Cost
5 When I park my car in the Valet Parking Lot for <parking
duration>
6 Then I will have to pay <parking costs>
7
8 Examples:
9 | parking duration | parking costs |
10 | 30 minutes | $ 12.00 |
11 | 3 hours | $ 12.00 |
12 | 5 hours | $ 12.00 |
13 | 5 hours 1 minute | $ 18.00 |
14 | 12 hours | $ 18.00 |
15 | 24 hours | $ 18.00 |
16 | 1 day 1 minute | $ 36.00 |
17 | 3 days | $ 54.00 |
18 | 1 week | $ 126.00 |
Step Definitions
The next step when working from the outside in is to hook up the steps to some program code. These hooks are called step definitions in Cucumber language. They depend heavily on the programming language in use. In Ruby, which is the default for Cucumber, the step definitions consist of closures surrounded by appropriate pattern matches. Each Given-step is introduced by the Given keyword plus a regular expression that matches the feature file line. The When- and Then-steps are defined in a similar way. Listing A.2 shows an example of such a definition for the above feature file.
Listing A.2. The step definitions for the above feature file
1 When /^I park my car in the Valet Parking Lot for (.*)$/ do |
duration|
2 $parkcalc.select('Valet Parking')
3 $parkcalc.enter_parking_duration(duration)
4 end
5
6 Then /^I will have to pay (.*)$/ do |price|
7 $parkcalc.parking_costs.should == price
8 end
Hook-up mechanisms for other programming languages are similar, although they make use of the language specific mechanisms like annotations in Java. If you would like to use a port to a different language, check the documentation for the actual syntax.
Production Code
At this point you can start developing the production system. In the airport example we used a mediation layer, which some people call page objects. It mediates the hooks to the actual implementation of the website. This appears to be a strategy most suitable for web applications. For non-web-UI code you will probably just start from the step definition code to drive all of your code.