This document provides an introduction to Behavior Driven Development (BDD) and the Cucumber testing framework. It discusses how BDD builds on Test Driven Development (TDD) principles by using examples and a ubiquitous language. Cucumber allows writing acceptance tests in a plain language format called Gherkin that can be executed and serves as documentation. Step definitions translate Gherkin steps into code to automate testing. The document demonstrates setting up a simple Cucumber test in Ruby and discusses expanding it to other programming languages and frameworks.

1. Behavior Driven Development
Pravin D’silva
MCA
Goa University

2. AGENDA
Introduction
 TDD
 BDD
 Cucumber
 Gherkin
 Step Definitions
 Demo (Ruby)
 How to extend


3. INTRODUCTION
People have a lot of ideas in mind.
 The key to convert ideas to software:
COMMUNICATION
 Various stakeholders involved in completing the
task


4. WRONG PERCEPTION

5. TEST DRIVEN DEVELOPMENT
Automated Test Cases
 Produce minimum code to pass test
 Refactor code to acceptable standards


6. TDD
Advantages:
 Programmers tend to be
more productive
 Can drive the design of a
program
 Offers the ability to take
small steps
 Can lead to more
modularized, flexible, and
extensible code
Shortcomings
 Reliance on unit tests
might not perform
sufficient full functional
testing
 Tests may share the
same blind spots with the
code
 Tests become part of the
maintenance overhead of
a project
 Rewrite the tests when
requirements change

7. WHAT IS BDD?
“BDD builds upon TDD by formalizing the good
habits of the best TDD practitioners.”
- Matt Wynne
So what are those good habits?
 Working outside-in, starting from a business or
organizational goal
 Using examples to clarify requirements
 Developing and using a ubiquitous language

8. USE OF EXAMPLES
Take care to write the acceptance tests as
examples that anyone on the team can read
 Get feedback from the business stakeholders
 Ensure the acceptance tests can easily be read and
written by anyone on the team

Easier to validate
 Readable by computer


TRUE VALUE OF ACCEPTANCE TESTS
communication
 collaboration tool


9. In BDD
Acceptance Tests
are
EXECUTABLE
SPECIFICATIONS

10. CUCUMBER TESTING STACK
Gherkin:
1. Specifications from plain-language text files
called features.
2. Each scenario is a list of steps for Cucumber
to work through
Step Definitions:
Map the business-readable language of each
step into Ruby code to carry out
whatever action is being described by the step.
Automation library:
One or two lines of Ruby that delegate
to a library of support code, specific to the
domain of your application.

11. CUCUMBER TESTING STACK

12. GHERKIN
Cucumber tests are expressed using a syntax
called Gherkin.
 Gherkin files: plain text and have a .feature
extension
 Use of Concrete Examples
 Lets take a scenario

Customers should be prevented from entering invalid
credit card details.

13. PROBLEMS
Customers should be prevented from entering invalid credit
card details.




Ambiguity and Misunderstanding
Lacks precision
Worthy but vague
Lets take another scenario
If a customer enters a credit card number that isn’t
exactly 16 digits long, when they try to submit the
form, it should be redisplayed with an error message
advising them of the correct number of digits.

14. FEATURE
Describe the features that a user will be able to enjoy when
using a program
Feature: Feedback when entering invalid credit card details.

In user testing we've seen a lot of people who made mistakes
entering their credit card. We need to be as helpful as possible
here to avoid losing users at this crucial stage of the transaction.
Background:
Given I have chosen some items to buy
And I am about to enter my credit card details
Scenario: Credit card number too short
When I enter a card number that's only 15 digits long
And all the other details are correct
And I submit the form
Then the form should be redisplayed And I should see a
message advising me of the correct number of digits

15. SCENARIO

Each scenario is a single concrete example of how the
system should behave in a particular situation

Scenarios all follow the same pattern:
1. Get the system into a particular state.
2. Poke it (or tickle it, or ...).
3. Examine the new state.





Start with a context, go on to describe an action, and
then finally check
that the outcome was what we expected. Each scenario
tells a little story describing something that the system
should be able to do.

16. SUPPORT FOR VARIOUS LANGUAGES
Gherkin support in Hindi
"native": "
feature": "
background": "
scenario": "
scenario_outline": "
examples": "
given": "*|
when": "*|
then": "*|
and": "*|
but": "*|
Norwegian:
Egenskap: Summering
For å unngå at firmaet går konkurs
Må regnskapsførerere bruke en
regnemaskin for å legge sammen tall
Scenario: to tall
Gitt at jeg har tastet inn 5
Og at jeg har tastet inn 7
Når jeg summerer
Så skal resultatet være 12

17. STEP LANGUAGES

Translates from plain language into Ruby

On the inside it tells your system what to do using
Ruby automation code.

Ruby has an incredibly rich set of libraries for
automating a whole variety of systems, from
JavaScript-heavy web applications to REST web
services.

18. FEATURE TO STEP DEFINITION
Feature:
Given I have $100 in my account
Regular Expression:
 /I have $100 in my Account/

19. KEYWORDS
Feature
 Background
 Scenario
 Given
 When
 Then
 And
 But
*
 Scenario Outline
 Examples


20. DEMO EXAMPLE

21. AFTER CREATING THE STEP DEFINITIONS FILE
The scenario has graduated from undefined to
pending.

22. Given /^the input "([^"]*)"$/ do |input|
@input = input
end

23. When /^the calculator is run$/ do
@output = `ruby calc.rb #{@input}`
raise('Command failed!') unless $?.success?
end
Calc.rb is not found

24. 
After calc.rb is created (still blank)

25. print eval(ARGV[0]) in calc.rb
Then /^the output should be "([^"]*)"$/ do |expected_output|
@output=expected_output
end

26. ADDING ANOTHER SCENARIO
Scenario Outline: Add two numbers
Given the input "<input>"
When the calculator is run
Then the output should be "<output>"
Examples:
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |

27. ALL TESTS PASSED

28. ADDITIONAL USES OF CUCUMBER
Databases
 Testing REST web services
 Capybara to Test Ajax Web Applications
 Aruba


29. USE CUCUMBER WITH JVM
Install Maven
 Install m2e plugins for Eclipse
 Add Cucumber dependencies in pom.xml
 Run Maven builds and test using Cucumber


30. REFERENCES
http://www.slideshare.net/tabaradetestare/t
dt-bdd-gabi-kis?from_search=14
https://github.com/cucumber/cucumber-jvm
http://rspec.info/
http://c0deattack.wordpress.com/2012/03/2
8/cucumber-jvm-with-cucumber-javacucumber-junit-example/
http://www.slideshare.net/ousam/cucumber
-presenation