Introduction to BDD

Copyright © 2015 SolutionsIQ Inc. All rights reserved.

6801 185th Ave NE, Suite 200Redmond, WA 98052solutionsiq.com1.800.235.4091

Behavior Driven development Introduction

PREPARED BYRanjith TharayilAgile Coach SolutionsIQ

2

Not again , Stop the crap we have seen this

3

History

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

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

5

Title: Customer withdraws cashAs 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 creditGiven the account is in creditAnd the card is validAnd the dispenser contains cashWhen the customer requests cashThen ensure the account is debitedAnd ensure cash is dispensedAnd ensure the card is returned

Scenario 2: Account is overdrawn past the overdraft limitGiven the account is overdrawnAnd the card is validWhen the customer requests cashThen ensure a rejection message is displayedAnd ensure cash is not dispensedAnd ensure the card is returned

6

The Philosophy

Product Owner

Developers Quality Assurance

Production Support

Business

7

Lack of Collaboration

8

The old school of thought , Inside Out

Test

Code

Spec

Inside Out

9

The BDD school of thought ,Outside in

Spec

Test

Code

Outside in

10

BDD pros

• 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 .

Scenario 1: Account is in credit

Given the account is in creditAnd the card is validAnd the dispenser contains cash

When the customer requests cash

Then ensure the account is debitedAnd ensure cash is dispensedAnd ensure the card is returned

Given Then

when

12

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

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

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

16

Background

17

Data Tables

18

Scenario Outline

19

Scenario Outline

20

Testing stack

21

BDD and test Pyramid

I have shamelessly copied this pic form Mike Cohn's book

22

Test iceberg

23

The flow

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

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

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?

27

The Gap

28

Complexity

29

When to use Behaviour Driven Development

30

How to measure complexity

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

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

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

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

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

37

BDD in a nut shell

I have shamelessly copied this pic from Rachel's

blog

38

Key Question

I have shamelessly copied this pic from Naresh Jain PPT

“

”

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

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

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