1. An Introduction to
Behavior Driven Design
Shawn Wallace
National Service Offering Lead
Application Development and Application Lifecycle Management
Senior Architect
Centric Consulting
13. A programmer is going out for a stroll one
evening. His wife asks him to swing by the
store and pick up a gallon of milk, and if they
had eggs, to get a dozen. He returned with
twelve gallons of milk and said "They had
eggs."
4
27. It’s NOT easy
• It is MUCH easier to slice up a backlog
horizontally
• Developers want to work horizontally
(efficiency argument)
http://simpleprogrammer.com/2011/11/21/understanding-the-vertical-slice/
32. Why Behavior Driven Design
• Work is done from the perspective of the
user
• Can slice vertically but narrowly
• Tests behavior of the system
• Executable requirements
• Need to move as fast
as business
• Appropriate feedback loop
• Manual regression is
EXPENSIVE
34. Acceptance Tests vs. Unit and
Integration Tests
• Unit Tests confirm that you built it
right (INSIDE OUT)
• Acceptance Tests confirm that you
build the right thing (OUTSIDE IN)
25
35. Benefits
• Implementing changes more efficiently
• Quick feedback
• Higher product quality
• Less rework
• Better work alignment to priority
(not just for agile teams)
26
36. • Describes how software should behave in plain text
• Gherkin
– Usable in many different human languages
– Features can be written and understood by both non/
technical project members
• Not a replacement for unit testing; it’s not a low
level testing/spec framework
• Easy to execute in Continuous Integration
environment (except MS TFS)
37. Technology Stack
• Cucumber - Domain Specification
• Ruby, JRuby or .NET - map cukes to
application
• UI testing framework - Watir, Watin,
Selenium, Capybara (headless),
anything that supports WebDriver
• Open source
• STRONG community support
28
41. Who’s Using the System
What are they doing?
Why do they care?
Features
42. Scenarios
• Features are defined by one or more
scenarios
• Sequence of steps thru the feature that
exercises on path
• Use BDD style – given-when-then
Scenario: <description>
<step 1>
…
44. • Given - Sets up preconditions, or context, for the
scenario
Scenarios
45. • Given - Sets up preconditions, or context, for the
scenario
• When - The action, or behavior, that we’re focused on
Scenarios
46. • Given - Sets up preconditions, or context, for the
scenario
• When - The action, or behavior, that we’re focused on
• Then - Checks post-conditions and verifies that the
right thing happened in the When stage
Scenarios
There is a lot here for...\n\ndevs, qa, ba and project leadership\n\nMeant to wet your whistle.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
A few things about me.\n
I &#x2018;fear the light&#x2019;\n\nWhy do I care about this?\n
\n
our existences are about precise communication\n
\n
How many agilists in the room\n
Nothing about standups, iterations, product owners, \n\nPeople analyze agile by checking how many of these practices you have put in place.\n\nAlready, we have lost our way.\n
The ceremony has become our goal\n
The ceremony has become our goal\n
Not about process, not about ceremony, about delivering working software\n
\n
\n
\n
\n
\n
\n
\n
Consider the ATM problem\n
Thinking about how to break apart a backlog into vertical slices requires us to step outside the understanding of the code and implementation and instead think about the backlog in small pieces of working functionality.\n
\n
\n
\n
IT needs to be able to move faster than the business must make decisions\n Tests from the perspective of the user\n Tests behavior of the system\n Executable requirements, codefied\n not disposable artifacts\n
TESTING IS PART OF REQUIREMENTS GATHERING\n TDD is a development practice\n These are fairly accurate ratios\n
\n
\n
\n
\n
Within the definition of a feature you can provide a plain text description of the story, focusing on three important questions:\n
\n
\n
\n
\n
\n
\n
\n
And can be used in any of the three sections\n It serves as nice shorthand for repeating the Given, When, or Then\n And stands in for whatever the most recent explicitly named step was\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
\nRuby and .NET\n
1) show feature code\n2) show features run\nRED IS BAD\nYELLOW IS NOT IMPLEMENTED\nGREEN IS GOOD\n3) show feature output\n