Bdd - history and myths

@sebrose http://claysnow.co.uk
BDD
-‐
(abbreviated)
history
and
mythology
Seb
Rose
Claysnow
Limited
@sebrose
Wednesday, 18 March 15

READING LIST ALERT

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-deﬁned outputs, resulting in the
delivery of working, tested software that
matters.
Dan North
http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

Chris Matts working with Rohit Darji
discover
“Pair Analysis”
2001

2002 (published 2005)

Chris Matts working with Sanela Hodzic
formalise
“Break the model”
2003

At the end of 2003, I decided it was time to
put my money – or at least my time – where
my mouth was. I started writing a replacement
for JUnit called JBehave, which removed any
reference to testing and replaced it with a
vocabulary built around verifying behaviour.
Dan North
http://dannorth.net/introducing-bdd/

Chris Matts and Dan North discuss
the power of “should”
on a ﬂight back from Agile 2004

Given/Then/When sees the light of day
abc.truemesh.com/archives/2004_11.html

Feature Injection & Real Options
2007

2012

2009 2011

Myth: It’s all about tools & automation

having conversations
is more important than
capturing conversations
is more important than
automating conversations
Liz Keogh
http://lizkeogh.com/2014/01/22/using-bdd-with-legacy-systems/

http://lizkeogh.com/2011/03/04/step-away-from-the-tools/
Have enough conversations to know how to get
started. Find out where the riskiest bits are, and
where the system behaves unusually. Chat.
Discuss. Discover. Work out how, and when,
you’re going to get feedback on the work you’re
about to do.
Then, and only then, reach for the tools.
Liz Keogh

https://leanpub.com/bdd

https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html
When you do BDD/Speciﬁcation by Example
and Outside-in, regression tests fall out at the
other end. They are a by-product of those
activities.Testing isn't the activity itself.
Cucumber is ﬁrst a foremost a collaboration
tool that aims to bring a common
understanding to software teams - across roles.
Aslak Hellesøy

Myth: It matters what you call it

http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/
What’s
the difference
between TDD,
ATDD, BDD
and SbE?
They’re
called
different
things

"Behaviour-Driven Development (BDD)
builds upon Test-Driven Development
(TDD) by formalising the good habits of
the best TDD practitioners."
-- The Cucumber Book, 2011
Living documentation

The best TDD
practitioners...
• Work from the outside-in, i.e. test-ﬁrst
• Use examples to clarify their requirements
• Develop and use a ubiquitous language

The best BDD
practitioners...
• Focus on value
• Discover examples collaboratively
• Create living documentation

Myth: We don’t need testers anymore

Myth:The more scenarios, the better

“I get paid for code that works, not for tests, so my
philosophy is to test as little as possible to reach a
given level of confidence ...
“I suspect this level of confidence is high
compared to industry standards”
http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

Myth:The scenarios should include all details

Imperative Declarative
Keep it Focussed:
Avoid incidental details

Feature: Sign up
Scenario: New user redirected to their own page
Given I am not logged in
And I visit the homepage
And I follow "Sign up"
And I fill in "Username" with "Matt"
And I fill in "Password" with "password"
And I fill in "Confirm password" with "password"
When I press "Sign up"
Then I should be on my feeds page
And I should see "Hello, Matt"

Feature: Sign up
When I sign up for a new account
Then I should be taken to my feeds page
And I should see a greeting message

Imperative vs
Declarative Style
Feature: The entire system
This feature illustrates what can happen when you
take the declarative style too far.
Scenario: It works
When I use the system
Then it should work perfectly

Imperative vs Declarative
Style
Feature: Sign up
Given I am not logged in
And I visit the homepage
And I follow "Sign up"
And I fill in "Username" with "Matt"
And I fill in "Password" with "password"
And I fill in "Confirm password" with "password"
And I press "Sign up"
Then I should be on my feeds page
And I should see "Hello, Matt"
Feature: Sign up
When I sign up for a new account
Then I should be taken to my feeds page
And I should see a greeting message

(A great blog post on this subject by Dan North)
http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/
Whose domain is it
anyway?

Myth:You don’t need development skills to write scenarios
This page unintentionally blank.

Seb
Rose
Twi6er:

@sebrose
Blog:

www.claysnow.co.uk
E-‐mail:

seb@claysnow.co.uk
Available Now

Bdd - history and myths

Recommended

Recommended

More Related Content

Similar to Bdd - history and myths

Similar to Bdd - history and myths (20)

More from Seb Rose

More from Seb Rose (20)

Recently uploaded

Recently uploaded (20)

Bdd - history and myths