Living Requirements using
Behavior Driven Development
May 8, 2015
Copyright © 2012 Accenture All rights reserved.
http://www.linkedin.com/in/martybradley
1
Outline
•
Behavior-Driven Development (BDD)
–
–
–
•
Rhythm of BDD
–
•
How does it fit in the agile process?
Gherkin language to create living requirements
–
•
What is it?
What are the benefits?
Who participates?
How do we define system behavior?
BDD Live Demo
Copyright© 2014 Accenture All rights reserved.
2
Behavior-Driven Development
What is BDD?
•
Behavior-Driven Development (BDD) is a disciplined
technique for building software in which the Product
Owner, a Programmer, and a Tester collaborate on
system behavior, also known as, acceptance criteria
for the feature that is about to implemented
Copyright© 2014 Accenture All rights reserved.
3
Behavior-Driven Development
What is BDD?
•
Behavior-Driven Development (BDD) is a disciplined
technique for building software in which the Product
Owner, a Programmer, and a Tester collaborate on
system behavior, also known as, acceptance criteria
for the feature that is about to implemented
A.K.A.
•
•
•
•
Acceptance Test Driven Development
Specification by Example
Story Testing
Functional Testing
Copyright© 2014 Accenture All rights reserved.
4
Behavior-Driven Development
Shared Understanding Made into Automated Tests
SHARED UNDERSTANDING
The biggest challenge in software development is to
understand what the customer REALLY needs, in
detail.
Behavior-Driven Development (BDD) encourages
creating a shared understanding and collaboration by
writing simple, scenario-based, single-source, living
specifications that business people and IT people can
read, easily understand, and quickly agree to that
provides clear traceability.
AUTOMATED TESTING
The most difficult part of DONEness is to ensure that
your story has been fully tested so that it satisfies
everything the Product Owner asked for and works
when integrated with the rest of the product.
Using a tool called Cucumber, the previously written
specifications can actually be turned into executable
tests.
Thus, the language of our shared understanding
becomes the language of our tests as well.
We use a special text syntax called Gherkin to build
scenarios…
GIVEN <condition>
WHEN <action>
THEN <result>
Copyright© 2014 Accenture All rights reserved.
5
Behavior-Driven Development
Shared Understanding Made into Automated Tests
It’s
ALIVE!
It’s
Alive!
AUTOMATED TESTING
SHARED UNDERSTANDING
The most difficult
The biggest challenge in software development
is to part of DONEness is to ensure that
yourneeds,
story has
understand what the customer REALLY
in been fully tested so that it satisfies
everything the Product Owner asked for and works
detail.
when integrated with the rest of the product.
Behavior-Driven Development (BDD) encourages
a tool called
creating a shared understanding andUsing
collaboration
by Cucumber, the previously written
specifications
writing simple, scenario-based, single-source,
livingcan actually be turned into executable
tests.
specifications that business people and
IT people can
read, easily understand, and quickly agree to that
provides clear traceability.
Thus, the language of our shared understanding
becomes the language of our tests as well.
We use a special text syntax called Gherkin to build
scenarios…
GIVEN <condition>
WHEN <action>
THEN <result>
Copyright© 2014 Accenture All rights reserved.
6
The Building Blocks to Agile Scrum Software Development
Gherkin
Given (Context or Event)
When (User Action)
Then (Outcome)
Copyright © 2012 Accenture All rights reserved.
•
Feature
•
Background
•
Scenario
•
Given
•
When
•
Then
•
And
•
But
•
*
•
Scenario Outline
•
Examples
7
The Building Blocks to Agile Scrum Software Development
Gherkin
Consumed by Cucumber
Given (Context or Event)
When (User Action)
•
Originally Ruby
•
Cucubmer-JVM (java)
•
Specflow (.NET)
Then (Outcome)
Copyright © 2012 Accenture All rights reserved.
8
Behavior-Driven Development
•
Like Test-Driven Development (TDD) but with Different
Scope
Test from the “outside-in”
– TDD fails when algorithm doesn’t exist (inside-out)
– Executable specification fails because a feature doesn’t
exist
– Helps teams build the right software product,
complementing technical practices that ensure that the
product is built right
–
Copyright© 2014 Accenture All rights reserved.
9
An Example
•
Seems clear, but is it?
–
•
Customer should be prevented from entering invalid
credit card information
Much more definitive
–
If a customer enters a credit card number that isn’t
exactly 16 digits long, when they try to submit the form, it
should be redisplayed with an error message advising
them of the correct number of digits.
The Cucumber Book, Matt Wynne & Aslak Hellesoy
Copyright© 2014 Accenture All rights reserved.
10
Rhythm of BDD
•
System Behavior
–
•
Safety Net
–
•
The system behavior is defined by a group of
scenarios that let you quickly add slices of
functionality to help learn about the feature
and it’s affect throughout the system
The behavioral tests act as a safety net that
allows us to make functional and structural
improvements to the code more freely without
introducing bugs
First “User”
–
The tests act as the first “User” of the code.
This results in code that is more easily
reusable
Copyright© 2014 Accenture All rights reserved.
11
Benefits of BDD
•
Usability
–
–
–
•
System functionality is more
deliberate
Developer is placed into the
paradigm of a user of the system
Fewer defects
Live Documentation
–
–
Living specifications
Tests describe the behavior of the
system
Copyright© 2014 Accenture All rights reserved.
12
Benefits of BDD
•
Higher Code Quality
–
Testable code tends to follow better
design patterns
•
•
•
–
•
Modularized
Flexible
Understandable
Testable code tends to have fewer lines
Confidence
–
–
Tests cover smaller, incremental slices of
the system making it easier to pivot or
grow a feature
Tests act as a safety net covering
existing functionality
Copyright© 2014 Accenture All rights reserved.
13
Benefits of BDD
•
Faster Delivery
–
–
Tests allow new features to be added more easily without
breaking existing ones
Misunderstanding of requirements appear earlier in the
development cycle and are more quickly eliminated –
less time debugging.
Copyright© 2014 Accenture All rights reserved.
14
Behavior-Driven Development
Living Specifications with the Gherkin Language
•
Gherkin defines example Scenarios in a Given-When-Then format to
create structure around the behaviors so that they can be automated
•
Gherkin gives us a lightweight structure for documenting examples of
the behavior our stakeholders want, in a way that it can be easily
understood both by the stakeholders and by Cucumber
•
Gherkin only has a few keywords allowing the team to build a domain
specific language (DSL) for common use in the system and in
conversations to promote a shared understanding
•
Gherkin uses user defined tags to organize scenarios
– @fast, @overnight, @web
Copyright© 2014 Accenture All rights reserved.
15
Feature discussion with PO
Me Likey
OUTSIDE-IN
Copyright© 2014 Accenture All rights reserved.
Huh?
INSIDE-OUT
16
A Basic Example using Gherkin: Check inbox
This scenario is good but has a lot of detail that makes it hard to read
Scenario: Check inbox
Given a User "Dave" with password "password”
And a User "Sue" with password "secret"
And an email to "Dave" from "Sue"
When I sign in as "Dave" with password "password"
Then I should see 1 email from "Sue" in my inbox
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
A Basic Example using Gherkin: Check inbox
Let’s get rid of the incidental details, the password in this case.
Scenario: Check inbox
Given a User "Dave"
And a User "Sue"
And an email to "Dave" from "Sue"
When I sign in as "Dave"
Then I should see 1 email from "Sue" in my inbox
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
A Basic Example using Gherkin: Check inbox
Let’s remove even more noise. This is very readable and easy
to maintain
Scenario: Check inbox
Given I have received an email from "Sue"
When I sign in
Then I should see 1 email from "Sue" in my inbox
That’s exactly what I meant!! What a great scenario.
I’m a great Product Owner!
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy
David Gijsbers, Eliassen Group
Lifecycle of a User Story
•
Iteration 1: PO creates user story and bulleted
acceptance criteria
•
Iteration 2: 3 Amigos groom the story adding
Given…When…Then scenarios
•
Iteration 3: Developer & tester work the story using
cucumber to generate the automation framework.
They use the red-green-refactor cycle to design,
develop, and test the feature
Note: Other artifacts can and should be attached to the user
story such as, design documents, emails, or anything else
that helps clarify the intent of the user story
Copyright© 2014 Accenture All rights reserved.
21
Behavior-Driven Development
A disciplined technique for building software in which
the Product Owner, a Programmer, and a Tester
collaborate on system behavior
Marty Bradley
www.bradasphere.com
www.linkedin.com/in/martybradley
Copyright© 2014 Accenture All rights reserved.
22
Some Tools and Helpful Links
•
Cucumber-JVM is a native Java implementation of
Cucumber
•
Specflow is a .NET implementation of Cucumber
•
https://cukes.info/ - Cucumber main
•
https://cucumber.pro/ - Online collaboration version
•
http://bradasphere.com/ - My blog containing some
BDD videos
Copyright© 2014 Accenture All rights reserved.
23