1) Behaviour-driven development (BDD) is an agile methodology that focuses on delivering working, tested software through collaboration between developers, testers and stakeholders. 2) BDD implements an application by describing its behavior through features and scenarios written from the perspective of stakeholders. Stories, acceptance criteria, executable examples and other tools are used to define requirements and guide development. 3) BDD aims to produce software that provides tangible value to stakeholders by being delivered incrementally, being easy to deploy and manage, and by adapting quickly to feedback through frequent testing and deployment.

1. Behaviour-Driven
Development
Writing software that matters
Dan North, ThoughtWorks
Liz Keogh, Lunivore

2. Part 1: Software that
doesn’t matter
2 © Dan North, ThoughtWorks

3. Failure modes – a field guide
The project comes in late
...or costs too much to finish
The application does the wrong thing
It is unstable in production
It breaks the rules
The code is impossible to work with
3 © Dan North, ThoughtWorks

4. How we deliver software
Planning
Analysis
Design
Deploy
Code
Test
t
Why do we do this?
4 © Dan North, ThoughtWorks

5. The exponential change curve
$ Planning
Analysis
Design
Deploy
Code
Test
t
5 © Dan North, ThoughtWorks

6. The exponential change curve
$
We fear this...
so we do t which
this... reinforces
this!
6 © Dan North, ThoughtWorks

7. If only we could deliver better...
Deliver features rather than modules
Prioritise often, change often
Only focus on high-value features
Flatten the cost of change
Adapt to feedback
Learn!
7 © Dan North, ThoughtWorks

8. What we would need
Adaptive planning
Streaming requirements
Evolving design
Code we can change
Frequent code integration
Run all the regression tests often
Frequent deployments
8 © Dan North, ThoughtWorks

9. Part 2: Software that
matters
9 © Dan North, ThoughtWorks

10. A loose definition of BDD
“Behaviour-driven development is
about implementing an application
by describing its behaviour from
the perspective of its stakeholders”
- Me 
10 © Dan North, ThoughtWorks

11. A more formal definition of 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.”
11 © Dan North, ThoughtWorks

12. ...second generation...
BDD is derivative
Derives from:
XP, especially TDD and CI
Acceptance Test-Driven Planning
Lean principles
Domain-Driven Design
Influenced by:
Neurolinguistic Programming (NLP)
Systems Thinking
12 © Dan North, ThoughtWorks

13. ...cycle of interactions...
BDD in six pictures
13 © Dan North, ThoughtWorks

14. ...cycle of interactions...
The roles in a BDD team
The stakeholders
The analysts (or BAs)
The testers (or QAs)
The developers
The project manager (or Boss)
14 © Dan North, ThoughtWorks

15. ...outside-in...
Who is this application for?
Vision
(or Purpose)
Outcome Outcome Outcome
Feature set Feature set Feature set Feature set
Features... Features... Features... ...
Stories... Stories... ...
Scenarios... ...
15 © Dan North, ThoughtWorks

16. ...clearly-defined outputs...
What’s in a story?
A story is a unit of delivery
Story 28 - View patient details
As an Anaesthetist
I want to view the Patient’s surgical history
So that I can choose the most suitable gas
16 © Dan North, ThoughtWorks

17. ...clearly-defined outputs...
Focus on the value
Story 28 - View patient details
In order to choose the most suitable gas
an Anaesthetist
wants to view the Patient’s surgical history
17 © Dan North, ThoughtWorks

18. ...clearly-defined outputs...
Focus on the value
Story 29 – Log patient details
In order to choose the most suitable gas
an Anaesthetist
wants other Anaesthetists to log the
Patient’s surgical history for later retrieval
18 © Dan North, ThoughtWorks

19. ...clearly-defined outputs...
Agree on “done”
Define scope using scenarios
Scenario – existing patient with history
Given we have a patient on file
And the patient has had previous surgery
When I request the Patient’s surgical history
Then I see all the previous treatments
19 © Dan North, ThoughtWorks

20. ...clearly-defined outputs...
Automate the scenarios
Make each step executable
Given we have a patient on file
In Ruby:
Given “we have a patient on file” do
# ...
end
In Java:
@Given(“we have a patient on file”)
public void createPatientOnFile() {
// ...
}
20 © Dan North, ThoughtWorks

21. ...clearly-defined outputs...
Code-by-example to implement
Also known as TDD
Start at the edges, with what you know
Implement outermost objects and operations
Discover collaborators, working inwards
and mock them out for now
Repeat until “Done”
If the model doesn’t “feel” right, experiment!
21 © Dan North, ThoughtWorks

22. ...clearly-defined outputs...
Code-by-example example
Scenario
Examples
Scenario
22 © Dan North, ThoughtWorks

23. ...clearly-defined outputs...
Good tools can help here
Cucumber or JBehave for stories
RSpec, XUnit for code examples
Mockito, Mocha, Moq for mocking
Be opinionated rather than dogmatic
with the tooling!
23 © Dan North, ThoughtWorks

24. ...clearly-defined outputs...
We keep the development artifacts
Examples become code tests
…and documentation
Scenarios become acceptance tests
which become regression tests
...and documentation
Automation is key
24 © Dan North, ThoughtWorks

25. Part 3: Getting the
words right
25 © Dan North, ThoughtWorks

26. 26 © Dan North, ThoughtWorks

27. Domain-driven design 101
Model your domain
...and identify the core domain
Create a shared language
...and make it ubiquitous
Determine the model’s bounded context
...and think about what happens at the edges
27 © Dan North, ThoughtWorks

28. The map is not the territory
There are many kinds of model
Each is useful in different contexts
There is no “perfect” domain model
So don’t try to create one!
Domain modelling takes practice
28 © Dan North, ThoughtWorks

29. A legacy domain modelling example
Map<int, Map<int, int>>
portfolioIdsByTraderId;
if (portfolioIdsByTraderId.get(trader.getId())
.containsKey(portfolio.getId())) {...}
becomes:
if (trader.canView(portfolio)) {...}
29 © Dan North, ThoughtWorks

30. We often manage multiple domains
You want to retrieve patient records
in Java, using Hibernate
so you define
class HibernatePatientRecordRepository {
What if your IDE did domain-specific fonts?
30 © Dan North, ThoughtWorks

31. Writing effective stories
Each story represents (part of) a feature
and each feature belongs to a stakeholder
Each stakeholder represents a domain
even the incidental stakeholders
Mixing domains within a scenario leads to brittle tests
What exactly is the scenario verifying?
What does it mean when things change?
“What does the stakeholder want from this story?”
31 © Dan North, ThoughtWorks

32. Conclusion
32 © Dan North, ThoughtWorks

33. Software that matters
...has tangible stakeholder value
...is delivered on time, incrementally
...is easy to deploy and manage
...is robust in production
...is easy to understand and communicate
BDD is a step in that direction
33 © Dan North, ThoughtWorks

34. Thank you
Any questions?
dan.north@thoughtworks.com
http://dannorth.net
@tastapod
liz@lunivore.com
http://lizkeogh.com
@lunivore
Google Group: BehaviorDrivenDevelopment
34 © Dan North, ThoughtWorks

35. Bibliography
Extreme Programming explained (2nd edition)
- Kent Beck
Domain-Driven Design - Eric Evans
The Art of Systems Thinking
and
The Way of NLP - Joseph O’Connor
35 © Dan North, ThoughtWorks