Topics covered are The problem ,History ,Philosophy , Collaboration, Specification by example , Scenarios , Cucumber JVM ,Gherkins ,Testing strategy , Testing Iceberg, Feature injection ,When to embrace BDD?,BDD for maintenance projects , the “dEep” model , TDD vs BDD

1. Copyright © 2015 SolutionsIQ Inc. All rights reserved.
6801 185th Ave NE, Suite 200
Redmond, WA 98052
solutionsiq.com
1.800.235.4091
Behavior Driven development
Introduction
PREPARED BY
Ranjith Tharayil
Agile Coach
SolutionsIQ

2. Not again , Stop the crap we have seen this
2

3. History
3
public class CustomerLookupTest
extends TestCase {
testFindsCustomerById() {
...
}
testFailsForDuplicateCustomers() {
...
}
...
}
renders something like this:
CustomerLookup
- finds customer by id
- fails for duplicate customers
- ...
Dan North
• Thought experiment
• AgileDox
• Chris Stevenson

4. “ ”
4
BDD is about implementing an application by describing it
from the point of view of its stakeholders

5. Title: Customer withdraws cash
As a customer, I want to withdraw cash from an ATM,so that I don’t have
to wait in line at the bank.
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
5
Scenario 2: Account is overdrawn past the
overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is
displayed
And ensure cash is not dispensed
And ensure the card is returned

6. The Philosophy
6
Product Owner
Developers Quality Assurance
Production Support
Business

7. Lack of Collaboration
7

8. The old school of thought , Inside Out
Test
Code
8
Spec
Inside Out

9. The BDD school of thought ,Outside in
9
Spec
Test
Code
Outside in

10. BDD pros
10
• High collaboration
• Early feedback
• Living documentation
• Domain language
• Executable Acceptance criteria
• Enables high Automation
• Enables Disciplined delivery

11. Writing scenarios , Modelling the systems as a state
Machine .
11
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Given Then
when

12. 1
let’s imagine you’re building a credit card payment
system
Customers should be prevented from entering invalid credit card
details.
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.

13. 1
Feature: Withdraw Cash
Most customers will use the ATM to make quick withdrawals of cash from
their checking or savings accounts. The ATM will only dispense $20 bills.
Scenario: Withdraw money from an
account
Given my account has a balance of $100
When I withdraw $20
Then $20 will be released by the cash
device
And my account balance will be $80
Scenario: Amount not a multiple of
$20
Given my account has a balance of
$100
When I try to withdraw $15
Then I will receive an error that I
must specify a multiple of $20
Scenario: Insufficient funds
Given my account has a balance of $40
When I try to withdraw $60
Then I will receive an insufficient funds
error

14. 14
Feature: Feedback when entering invalid credit card details
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
Scenario: Expiry date invalid
When I enter a card expiry date that's
in the past
And all the other details are correct
And I submit the form
Then the form should be redisplayed
And I should see a message telling me
the expiry date must be wrong

15. Background
15

16. Background
16

17. Data Tables
17

18. Scenario Outline
18

19. Scenario Outline
19

20. Testing stack
20

21. BDD and test Pyramid
21
I have shamelessly copied this pic form Mike Cohn's book

22. Test iceberg
22

23. The flow
23
N-1 N N+1
» Sprints
spec
» Sprint planning
» Pull only those with spec ready» Three Amigo
Meetings
» BA ,PO
» Developers
» QA
» Production Support
» Any one who could
contribute in scenario
identification
• Disciplined delivery
• Working agreements
• DOR
• DOD
• Less risk of failure

24. Scenario Identification
Functional:
Happy path
Sad path
Constraints
Quality
attributes
24

25. Feature injection
The aim of Feature Injection is to flesh out the minimum set of features that will provide
the most benefit to stakeholders in terms of achieving their business goals
25
1. Hunt the value.
2. Inject the features.
3. Spot the examples

26. When to Embrace BDD ?
The problem
• Full team participation
• ROI
• waste of time
“Assumption BDD is practices in its fullest of its sprits” and still there is question on
ROI
Abstract : Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build
the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent
past have reaped benefits from this technical practice, while some teams complain that are yet to find any
value. This article focuses on answering two questions; Why BDD might not always be the right choice? What
are the ideal conditions when teams should adopt it?
26

27. The Gap
27

28. Complexity
28

29. When to use Behaviour Driven Development
29

30. How to measure complexity
30
Points Complexity Description
1 Just about everyone in the world has done this
2 Lots of people have done this, including someone on our team.
3 Someone in our company has done this, or we have access to expertise
4 Someone in the world did this, but not in our organization (and probably
at a competitor)
5 Nobody in the world has ever done this before
Second Order ignorance
We say second order of ignorance exist if “when I don't know that I
don't know something”.
Liz Keogh

31. BDD for maintenance projects ?
• Lots of legacy code 
• Enhancements
• Defect fix
• Production issues
31

32. Adapting BDD for software maintenance projects
using the “dEep” model.
we can categories the type of work into 4 different types .
32
d , defects
E ,Complex Enhancement
e ,Simple Enhancements
p , urgent production issues

33. E , Complex Enhancements
• classical BDD style:
• 3 Amigo meetings
• specification by example
• pull based
• TDD strategy , etc
• working agreements ,DOR ,DOD
• highly disciplined
• Full team participation
33

34. e ,Smaller Enhancements
• Skip 3 Amigo meetings
• cover the module with scenarios based test
• Express new requirements in the form of a scenario
• get the spec reviewed by BA/PO , dev ,QA .
• Highly pragmatic approach ,
• (need basis ) UT or E2E test
• test first approach or TDD
34

35. d, Defects
• d came to existence because there was a hole in your test pyramid
• fix the hole that caused the issue ,may be a test or two , be pragmatic
• fix the code , again test first strategy
35

36. p, urgent production issues
• fix the code first & deploy
• put a card in your back log to fix the hole in test pyramid which caused the
issues
• Test last strategy 
36

37. 37
BDD in a nut shell
I have shamelessly copied this pic from Rachel's blog

38. Key Question
38
I have shamelessly copied this pic from Naresh Jain PPT

39. “
”
BDD is a second-generation, outside-in, pull-based,
multiple-stakeholder, multiple-scale, high-automation,
agile methodology. It describes a cycle of interactions with
well-defined outputs, resulting in the delivery of working,
tested software that matters.

40. 40
“BDD doesn't come with BRAINS kindly use
yours”

41. 41
Thank you!
solutionsiq.com / 1.800.235.4091
» Acknowledgments :
» Sharad Julka for proposing the catchy name “dEep”
» Images in this document are shameless coped from 2 books
» BDD in Action ,Manning
» The Cucumber Book