Don’t start with login!

BDD for collaboration and testing

Nate Peterson@njpetersonpa

- BDD overview - Scenarios - Practices that helped - Anti-patterns - Applying BDD

“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.”

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

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

--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 != toolsand

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

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

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 language of 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 simple by 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 unnecessary or

irrelevant context

Don’t

Keep the context to just enough

Do

Imperative vs.

declarativescenarios

Given John enters john.doe@gmail as the username

and P@55W0rd as the password

When he logs inThen it should be successful

Given John has valid credentialsWhen he logs in

Then he it should be successful

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

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

Applying BDD

People don’t often speak using Given / When / Then

http://lizkeogh.com/2014/09/01/deriving-gherkin-from-real-conversations/

Can you give me an example?

What if…?

Teams get bored with having conversations

Getting buy-in

Benefits of BDD

Shared understanding

Reduces waste / feedback loops

Discover unknowns

building the right thing

Software that matters

@njpetersonpa

ResourcesDan 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