Behavior Driven Development

&

Specification by Example

Arnauld Loyer - @aloyer

With

S

Arnauld Loyer

@aloyer Software Craftsman

BDD fan bo

y

Authentic Developer

since 2000!

@aloyer

Exercise: Draw a 12 points Star

@aloyer

Exercise: Draw a 12 points Star

or or

@aloyer

"Sherlock saw the man with binoculars"

@aloyer

Un bon cahier des charges peut être caractérisé par !les 7 qualificatifs suivants [IEEE 830]:!!

• non ambigu!• complet!• vérifiable!• consistant!• modifiable!• traçable!• utilisable durant la maintenance

Attention

ceci e

st un

e « Bulle

t Attack »

@aloyer

Chaos Reporthttp://blog.standishgroup.com/@aloyer

Chaos Reporthttp://blog.standishgroup.com/

Project Challenged Factors 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% !Project Impaired Factors % of 1. Incomplete Requirements 13.1% 2. Lack of User Involvement 12.4% 3. Lack of Resources 10.6% 4. Unrealistic Expectations 9.9% 5. Lack of Executive Support 9.3% 6. Changing Requirements & Specifications 8.7% 7. Lack of Planning 8.1% 8. Didn't Need It Any Longer 7.5% 9. Lack of IT Management 6.2% 10. Technology Illiteracy 4.3%

Project Challenged Factors 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% !Project Impaired Factors % of 1. Incomplete Requirements 13.1% 2. Lack of User Involvement 12.4% 3. Lack of Resources 10.6% 4. Unrealistic Expectations 9.9% 5. Lack of Executive Support 9.3% 6. Changing Requirements & Specifications 8.7% 7. Lack of Planning 8.1% 8. Didn't Need It Any Longer 7.5% 9. Lack of IT Management 6.2% 10. Technology Illiteracy 4.3%

Project Challenged Factors 1. Lack of User Input 12.8% 2. Incomplete Requirements & Specifications 12.3% 3. Changing Requirements & Specifications 11.8% 4. Lack of Executive Support 7.5% 5. Technology Incompetence 7.0% 6. Lack of Resources 6.4% 7. Unrealistic Expectations 5.9% 8. Unclear Objectives 5.3% 9. Unrealistic Time Frames 4.3% 10. New Technology 3.7% !Project Impaired Factors % of 1. Incomplete Requirements 13.1% 2. Lack of User Involvement 12.4% 3. Lack of Resources 10.6% 4. Unrealistic Expectations 9.9% 5. Lack of Executive Support 9.3% 6. Changing Requirements & Specifications 8.7% 7. Lack of Planning 8.1% 8. Didn't Need It Any Longer 7.5% 9. Lack of IT Management 6.2% 10. Technology Illiteracy 4.3%

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

2005 Survey: The Top Challenges Facing Business Analysts

Business Improvement Architect’s research survey of Business Analysts attending Project World/

Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of

the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two

challenges facing their organizations in managing business requirements.!

!-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

2005 Survey: The Top Challenges Facing Business Analysts

Business Improvement Architect’s research survey of Business Analysts attending Project World/

Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of

the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two

challenges facing their organizations in managing business requirements.!

!-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm

Why IT Projects Fail

1. Lack of Governance!

2. Internal Politics!

3. Poor communication between business and IT!

4. Unclear expectations!

! http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

2005 Survey: The Top Challenges Facing Business Analysts

Business Improvement Architect’s research survey of Business Analysts attending Project World/

Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of

the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two

challenges facing their organizations in managing business requirements.!

!-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm

Why IT Projects Fail

1. Lack of Governance!

2. Internal Politics!

3. Poor communication between business and IT!

4. Unclear expectations!

! http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4

Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes

(2005)!

http://spectrum.ieee.org/computing/software/why-software-fails!

!Among the most common factors:!

* Unrealistic or unarticulated project goals!

* Inaccurate estimates of needed resources!

* Badly defined system requirements!

* Poor reporting of the project's status!

* Unmanaged risks!

* Poor communication among customers, developers, and users!

* Use of immature technology!

* Inability to handle the project's complexity!

* Sloppy development practices!

* Poor project management!

* Stakeholder politics!

* Commercial pressures

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

2005 Survey: The Top Challenges Facing Business Analysts

Business Improvement Architect’s research survey of Business Analysts attending Project World/

Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of

the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two

challenges facing their organizations in managing business requirements.!

!-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm

Why IT Projects Fail

1. Lack of Governance!

2. Internal Politics!

3. Poor communication between business and IT!

4. Unclear expectations!

! http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4

Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes

(2005)!

http://spectrum.ieee.org/computing/software/why-software-fails!

!Among the most common factors:!

* Unrealistic or unarticulated project goals!

* Inaccurate estimates of needed resources!

* Badly defined system requirements!

* Poor reporting of the project's status!

* Unmanaged risks!

* Poor communication among customers, developers, and users!

* Use of immature technology!

* Inability to handle the project's complexity!

* Sloppy development practices!

* Poor project management!

* Stakeholder politics!

* Commercial pressures

Seven Reasons IT Projects Fail - February 2012 !1. Poor Project Planning and Direction 2. Insufficient Communication 3. Ineffective Management 4. Failure to Align With Constituents and Stakeholders !

http://www.ibmsystemsmag.com/power/Systems-Management/Workload-Management/project_pitfalls/?page=2!

@aloyer

The Bull Survey (1998) !All the managers interviewed had previously taken the lead in integrating large systems within organizations in the Times Top 100.!!Project Evaluation Criteria !The main IT project failure criteria identified by the IT and project managers were:!* missed deadlines (75%)!* exceeded budget (55%)!* poor communications (40%)!* inability to meet project requirements (37%).!!http://www.it-cortex.com/Stat_Failure_Cause.htm

2005 Survey: The Top Challenges Facing Business Analysts

Business Improvement Architect’s research survey of Business Analysts attending Project World/

Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of

the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two

challenges facing their organizations in managing business requirements.!

!-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm

Why IT Projects Fail

1. Lack of Governance!

2. Internal Politics!

3. Poor communication between business and IT!

4. Unclear expectations!

! http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4

Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes

(2005)!

http://spectrum.ieee.org/computing/software/why-software-fails!

!Among the most common factors:!

* Unrealistic or unarticulated project goals!

* Inaccurate estimates of needed resources!

* Badly defined system requirements!

* Poor reporting of the project's status!

* Unmanaged risks!

* Poor communication among customers, developers, and users!

* Use of immature technology!

* Inability to handle the project's complexity!

* Sloppy development practices!

* Poor project management!

* Stakeholder politics!

* Commercial pressures

Seven Reasons IT Projects Fail - February 2012 !1. Poor Project Planning and Direction 2. Insufficient Communication 3. Ineffective Management 4. Failure to Align With Constituents and Stakeholders !

http://www.ibmsystemsmag.com/power/Systems-Management/Workload-Management/project_pitfalls/?page=2!

The Most Common Factors for the failure of Software Development Project !1. Lack of Customer or User Involvement 2. Unclear goals and objectives 3. Poor Requirement Set 4. Lack of Resources 5. Failure to communicate and act as a team !!

Volume 1, No. 11, January 2013 ISSN – 2278-1080 !The International Journal of Computer Science & Applications!http://www.journalofcomputerscience.com/2013Issue/Jan13/V1No11Jan13P044.pdf

@aloyer

I want

« A »A

BDD in 5 minutes 10@aloyer

I want

« A »Let’s Specify

« B » A

BDD in 5 minutes 10@aloyer

I want

« A »Let’s Specify

« B »

B

A

BDD in 5 minutes 10@aloyer

I want

« A »

I Will Test

« C »

C

B

A

Let’s Specify

« B »

11BDD in 5 minutes 11

BDD in 5 minutes 12

I want

« A »

I Will Test

« C »

Let’s Develop

« D »

D

C

B

A

Let’s Specify

« B »

D

C

B

A

Developed

Specified

Tested

Wanted

13BDD in 5 minutes 13

D

C

B

A

Developed

Specified

Tested

Wanted

Humpff

13BDD in 5 minutes 13

BDD in 5 minutes 14

BDD in 5 minutes 14

NooOOOOooo!!

"is this a bug or is this not a

bug?"

a bug?

a feature?

an enhancement?

a beature?

@aloyer

@aloyer

@aloyer

3 steps

3 models

3 interpretations

@aloyer

3 steps

3 models

3 interpretations

@aloyer

3 visions

1 model

1 goal

@aloyer

Working together to find better solutions

Use real-world examples to build a shared understanding of the domain

People understand requirements best using concrete examples.

Examples clear up ambiguity and misunderstandings.

Examples expose missing requirements.

Examples force everyone to think harder about a problem.

@aloyer

Test

First

Test

Driven

Develo

pmen

t

Behav

ior Driv

en Dev

elopm

ent!

« 200

3 » Execu

table

Specifi

catio

n!

& Automati

on

Explor

atory

Example

s!

& Discus

sion

@aloyer

http://pencilink.blogspot.fr/2010/10/iron-man-160-jim-starlin-cover-steve.html

It’s NOT about tools

@aloyer

http://pencilink.blogspot.fr/2010/10/iron-man-160-jim-starlin-cover-steve.html

It’s NOT about tools

It’s about Communication and Behavior!

@aloyer

http://ungoliantschilde.tumblr.com/post/78793890826/ungoliantschilde-barry-windsor-smith-that

It’s NOT about Testing

@aloyer

http://ungoliantschilde.tumblr.com/post/78793890826/ungoliantschilde-barry-windsor-smith-that

It’s NOT about Testing

It’s about Exploring the Unknown

@aloyer

It’s not about Silo!Or Acceptance

Criteria

@aloyer

It’s not about Silo!Or Acceptance

Criteria

It’s about

Sharing

and

Understanding

@aloyer

It’s about Driven Development!

@aloyer

Examples Tests

Requirements

elaborate

can become

verify

@aloyer

Three Amigos

@aloyer

BDD is about conversation

@aloyer

BDD is about conversation

BDD is not about tools

@aloyer

@aloyer

What?

How!

@aloyer

Why?

Goal?

Business Value?

What?

How!

@aloyer

Why?

Goal?

Business Value?

IntentionWhat?

How!

@aloyer

29

Why?

Goal?

Business Value?

In order to <achieve the vision>

Feature: ...

As a <stakeholder>I want <value>

IntentionWhat?

How!

@aloyer

Why?

Goal?

Business Value?

In order to <achieve the vision>

Feature: ...

As a <stakeholder>I want <value>

Intention

As a <role>I want <goal>So that <value>

User focused

What?

How!

@aloyer

No Narrative

No Business Value

Unnecessary Feature !

@aloyer

Feature

Criteria!(Rules)

Criteria!(Rules)

What is it supposed to do

Example

Example

Example

Example

Illustration of

Acceptance Criteria vs Example @aloyer 32

Example

Examples of Examples @aloyer 33

Password OK/KO Reason

Arn4uld KO No special characters

arnauld$ KO No upper case

Arn4ld$ OK

Z0€ KO too short

Last Passwords Password OK/KO

J0hn$!$m1th!

Arn4ld$Arn4ld$ KO

J0hn$!Arn4ld$!$m1th

Arn4ld$ KO

Arn4ld$!J0hn$!$m1th

Arn4ld$ OK

In order to...Feature: ...

As a...I want to...Scenario: ...

@aloyer

In order to...Feature: ...

As a...I want to...Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

@aloyer

In order to...Feature: ...

As a...I want to...Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

BDD uses examples to illustrate

behavior

@aloyer

Gherkin - Scenario - Given/When/Then

Scenario: Some determinable business situation

When <an action is performed on the system>Then <an expected outcome should be observed>

Given <a specific context>

Every scenario consists of a list of steps

35

Resulting!StateInitial!Context

Given

Given

Given

Given

When

ThenWhen

Then

Then

Transition@aloyer

Gherkin - Scenario - Given/When/Then

Given!!The purpose of givens is to put the system in a known state before interacting with it. They defines the preconditions. !• Indicate which environment to use • Insert values in database • Fill context with predefined users • Log user • …

Given there are no users on site!Given the database is clean Given the predefined high and volatile stocks Given I am logged in as "Balthazar"

36@aloyer

Gherkin - Scenario - Given/When/Then

When!!The purpose of when steps is to describe the key action performed (the state transition). !• Trigger commands • Interact with the UI • Go to a specific page, Fill a form, Select books or CDs • Launch a batch • …

When I log in the application as "Gaspard" When I look at my profile!When I book the deal When I generate the financial report

37@aloyer

Gherkin - Scenario - Given/When/Then

Then!!The purpose of Then steps is to observe outcomes. The observations should be related to the business value/benefit of the feature. !• Feedback message • Generated document, Mail sent • Command output • Data updated • …

It should be something related to

the Given/When

Then I should see a welcome message Then the report should contain the created deal!Then the result should be 42

39@aloyer

Why do YOU

like should?

It encourages

debate, and

constant Questioning

of the premise of the

application you are

developing.

Dan North, March 2005

DMZ

BDD Approach

40Gherkin - Should 40@aloyer

Gherkin - Scenario - Given/When/Then

Scenario: Some determinable business situation !

Given a specific context Given another specific context Given an even other specific context When an action is performed on the system When another action is performed on the system Then expected outcome Then an other expected outcome Then an even other expected outcome

41@aloyer

Gherkin - Scenario - And/But

Scenario: Some determinable business situation !

Given a specific context And another specific context But an even other specific context When an action is performed on the system And another action is performed on the system Then expected outcome And an other expected outcome But an even other expected outcome

Given/When/Then + And/But

42@aloyer

Gherkin - Sample

Feature: Trade Execution !In order to reduce the risk of other clearing firm failing to honor its trade settlement obligations As a clearing firm I want that a clearing house stands between me and the other firm

Scenario: New trade is confirmed between the bank and counterparty !

Given A new trade between the bank and counterparty When the trade is captured Then it should be sent to clearing house for matching

43@aloyer

Gherkin - Sample

Feature: Trade Execution !In order to reduce the risk of other clearing firm failing to honor its trade settlement obligations As a clearing firm I want that a clearing house stands between me and the other firm

Scenario: New trade is confirmed between the bank and counterparty !

Given A new trade between the bank and counterparty When the trade is captured Then it should be sent to clearing house for matching

44

Must give a quick overview of what scenario is doing

@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers

45@aloyer

Gherkin - Sample Calculator Feature 46

What could be

the first use case?

@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers !

Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

47@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers !

Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

47

It should be something related to

the Given/When‟

@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers !

Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

48

It should be something related to

the Given/When‟Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 23 Should Fail!

@aloyer

Gherkin - Sample Calculator Feature 49

What could be the next

Scenario?

@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers

!Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

!Scenario: Addition of a positive number and a negative number !

Given two numbers 11 and -3 When I add them Then the result should be 8

50@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers

!Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

!Scenario: Addition of a positive number and a negative number !

Given two numbers 11 and -3 When I add them Then the result should be 8

51

Reusable Step

@aloyer

Gherkin - Sample Calculator Feature

Feature: Addition feature !

In order to perform mathematical operations As an accounting officer I want to be able to add numbers

!Scenario: Addition of positive numbers !

Given two numbers 12 and 7 When I add them Then the result should be 19

!Scenario: Addition of a positive number and a negative number !

Given two numbers 11 and -3 When I add them Then the result should be 8

52

Parameterized Step

@aloyer

@aloyer

@aloyer

@aloyer

@aloyer

In order to...Feature: ...

As a...I want to...

Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

@aloyer

In order to...Feature: ...

As a...I want to...

Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

@aloyer

In order to...Feature: ...

As a...I want to...

Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

Examples help discover things early

@aloyer

In order to...Feature: ...

As a...I want to...

Scenario: ...Given <a context>When <an event happens>Then <an outcome should occur>

One may discover that one doesn't know

but others do!

@aloyer