01.4.txt

1.4  Cucumber

As you’ll read about in Chapter 11, Writing Software That Matters, on page  
138,  BDD  is  a  full-stack  agile  methodology.  It  takes  some  of 
its  cues  from  Extreme  Programming,  including  a  variation  of  Accep- 
tance  Test–Driven  Development  called  Acceptance  Test–Driven  Plan- 
ning (ATDP).

In  ATDP,  we  use  customer  acceptance  tests  to  drive  the  
development
of  code.  Ideally,  these  are  the  result  of  a  collaborative  effort  
between the customer and the delivery team. Sometimes they are written by 
the delivery team and then reviewed/approved by the customer. In either 
case,  they  are  customer  facing  and  must  be  expressed  in  a  
language and format that customers can relate to. Cucumber gives us that 
lan- guage and format.

Cucumber  reads  plain-text  descriptions  of  application  features  with 
example scenarios and uses the scenario steps to automate interaction with 
the code being developed. Here’s an example:

Line 1  Feature: pay bill on-line
-
-  In order to reduce the time I spend paying bills
-  As a bank customer with a checking account
5  I want to pay my bills on-line
-
-  Scenario: pay a bill
-  Given checking account with $50
-  And a payee named Acme
10  And an Acme bill for $37
-  When I pay the Acme bill
-  Then I should have $13 remaining in my checking 
account
-  And the payment of $37 to Acme should be listed in 
Recent Payments

 Cucumber  Seeds  
  

Even  before  we  started  exploring  structures  and  syntax  for RSpec, 
Dan North had been exploring a completely different model for a BDD tool.

He wanted to document and drive behavior in a simplified lan- guage that 
could be easily understood by customers, develop- ers, testers, business 
analysts, and so on. The early result of that exploration was the JBehave 
library, which is still in active use and development.

Dan ported JBehave to Ruby as RBehave, and we merged it into RSpec as the 
Story Runner. It only supported scenarios writ- ten in Ruby at first, but 
we later added support for plain text, opening up a whole new world of 
expressiveness and access. But as new possibilities were revealed, so were 
limitations.

In the spring of 2008, Aslak Hellesoy set out to rewrite RSpec’s Story 
Runner with a real grammar defined with Nathan Sobo’s Treetop library. 
Aslak dubbed it Cucumber at the suggestion of his fiancee, Patricia 
Carrier, thinking it would be a short-lived working title until it was 
merged back into RSpec. Little did either of them know that Cucumber would 
develop a life of its own.




Everything  up  to  and  including  the  Scenario  declaration  on  line  7 
 is treated  as  documentation  (not  executable).  The  subsequent  lines  
are steps in the scenario.

In Chapter 4, Automating Features with Cucumber , on page 53, you’ll be 
writing step definitions in Ruby. These step definitions interact with the 
code being developed and are invoked by Cucumber as it reads in the 
scenario.
Don’t worry if that doesn’t make perfect sense to you just yet. For now, 
it’s only important to understand that both RSpec and Cucumber help us  
specify  the  behavior  of  code  with  examples  that  are  programmati- 
cally tied to that code. The details will become clear as you read on.


We  use  Cucumber  to  describe  the  behavior  of  applications  and  use 
RSpec  to  describe  the  behavior  of  objects.3 If  you’ve  ever  done  
TDD before, you’re probably familiar with the red/green/refactor cycle. 
With the  addition  of  a  higher -level  tool  like  Cucumber,  we’ll  
actually  have two concentric red/green/refactor cycles, as depicted in 
Figure 1.1, on the following page.

Both  cycles  involve  taking  small  steps  and  listening  to  the  
feedback you get from the tools. We start with a failing step (red) in 
Cucumber (the  outer  cycle). To  get  that  step  to  pass,  we’ll  drop 
 down  to  RSpec (the inner cycle) and drive out the underlying code at a 
granular level (red/green/refactor).