Build something that your users want

An introduction to BDD

Nate Peterson@njpetersonpa

“Behaviour-driven-development is about implementing an application by describing its behaviour from the perspective of its stakeholders”

--Dan North

“BDD’s focus is on the discovery of stuff we didn’t know about, particularly around the contexts in which scenarios or examples take place. …”

--Liz Keogh

“.. It [BDD] describes a cycle of interactions with well defined outputs resulting in delivery of working, tested software that matters.”

--Dan North

“BDD practitioners explore, discover, define, and drive out desired behavior of software using conversations, concrete examples, and automated tests”

--Matt Wynne

Having conversations with domain experts

and using examples

to gain a shared understanding of the desired behavior

and discover unknowns

Having conversations with domain experts

and using examples

to gain a shared understanding of the desired behavior

and discover unknowns

Having conversations with domain experts

and using examples

to gain a shared understanding of the desired behavior

and discover unknowns

Having conversations with domain experts

and using examples

to gain a shared understanding of the desired behavior

and discover unknowns

Having conversations with domain experts

and using examples

to gain a shared understanding of the desired behavior

and discover unknowns

Building the right thingvs.

building the thing right

BDD != automation

It’s not all about the tools

The best tools won’t solve your customer’s problems if you

don’t know or understandthem

Scenarios

Scenarios are a way for describing behavior

Given a contextWhen an event happens

Then an outcome should occur

Given Nate purchased a shirt and the shirt cost $20

When he returns the shirtThen he should get $20 refunded

…Simply by getting the business users, the analysts, the testers and the developers to

adopt this vocabulary of “given/when/then”, they discover that a

world of ambiguity falls away.

-- Dan North

Given a contextWhen an event happens

Then an outcome should occur

Given a contextWhen an event happens

Then an outcome should occur

Given a contextWhen an event happens

Then an outcome should occur

Given Nate purchased a shirt and the shirt cost $20

When he returns the shirtThen he should get $20 refunded

Is there a context which this event will create a different outcome?

Given Nate purchased a shirt for $20and he does not have the receipt

When he returns the shirtThen he should be able to exchange the shirt for another shirt of the same kind

Is this the only outcome that matters?

Given Nate purchased a shirt for $20and the shirt has a hole in it

and he does not have the receiptWhen he returns the shirt

Then he should be able to exchange the shirt for another shirt of the same kind

and the shirt should be processed as damaged

and the store inventory should be decremented

ScenarioDos and Don’ts

Make the scenarios user interface

specific

Don’t

Given Nate has $20 in his savings accountWhen he navigates to the transfer screenand enters $20 into the transfer amount

text boxand clicks the transfer button

then the account balance should be $40

Don’t

Make the scenarios implementation

specific

Don’t

Use the languageof the business

Do

Address multiple domains in a single scenario

Don’t

Given Nate purchased a shirt and the shirt cost $20

When he returns the shirtThen he should get $20 refundedand the store inventory should be

incremented by 1

Don’t

Keep scenarios simpleby focusing on a single domain

at a time

Do

Given Nate purchased a shirt and the shirt cost $20

When he returns the shirtThen he should get $20 refunded

Given the store as 10 shirts in inventoryWhen 1 shirt is returned

Then the inventory for that shirt should be 11

Do

Add unnecessaryor

irrelevant context

Don’t

Keep the context to just enough

Do

Acceptance criteria vs.

Scenarios

Given Nate purchased a shirt on December 24th 2014

When he returns the shirt on April 28th 2015

Then he should be denied a refund

Given a shirt was purchasedwhen it is returned

and the purchase date is older than the allowed time frame

then it should not be refunded

Making BDD work

If you’re not having conversations

then you’re not doing BDD-- Liz Keogh

Having conversations

is more important than capturing conversations

is more important than automating conversations

-- Liz Keogh

Three Amigos

domain expert – developer – tester

domain expert

The person who knows the business rules

developer

The person who thinks inthe solution space

tester

The person who thinks inthe problem space

No hand-offs

The business writes the scenarios and gives them to the team

The developer writes the scenarios without talking to the team

The tester writes the scenarios after code finished for automated testing

Takes practice to write good scenarios

People don’t often speak usingGiven / When / Then

Can you give me an example?

What if…?

Getting buy-in

Teams get bored with having conversations

Benefits of BDD

Shared understanding

Reduces waste / feedback loops

building the right thing

Software that matters

Something your users want

@njpetersonpa

Resources

Dan North - http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/Dan North - http://dannorth.net/whats-in-a-story/Dan North - http://dannorth.net/introducing-bdd/Liz Keogh - http://lizkeogh.com/behaviour-driven-development/Liz Keogh - http://www.slideshare.net/lunivore/behavior-driven-development-11754474Seb Rose - http://www.slideshare.net/sebrose/bdd-history-and-myths