3. Background
• At TechTalk we are trying to live a BDD
process for several years
• We started SpecFlow in 2009 out of a
need to implement BDD
• We have implemented and improved
our BDD process and knowledge in
many projects
• … we are still learning The research is partially supported by the
project of Eötvös Loránd University:
TÁMOP-4.2.1.B-09/1/KMR-2010-0003
3
4. BDD – A definition from Dan North
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, Agile Testing, Specifications and BDD Exchange 2009
4
5. The BDD Development Process
… how we live it
Requirements Analysis
Executable & Automated
Specifications
Improving Feedback with a
Transparent Development Process
Living Documentation
5
6. Requirements Analysis & Colaboration
We want to encourage new users to place an order.
Therefore we are going to offer 10% discount on
every initial order.
Register as “bart_bookworm”
Go to “/catalog/search”
Enter “ISBN-0955683610”
Click “Search”
Click “Add to Cart”
Click “View Cart”
Verify “Subtotal” is “$33.75”
public void CalculateDiscount(Order order)
{
if (order.Customer.IsNew)
order.FinalAmount = Math.Round(order.Total * 9/10);
}
6
8. Outcome of Requirements Analysis
• Sprint Planning
•User Stories
•Acceptance Criterias
•… illustrated by Examples
8
9. Executable & Automated
Specifications
Requirements Analysis
Executable & Automated
Specifications
Improving Feedback with a
Transparent Development Process
Living Documentation
9
10. Automation
• Why?
• iterative & incremental
development demand a
continuous feedback
• Challenges
• Abstraction vs. Reliability
• Trust
• Shared Understanding
• Effort
10
14. Scripts vs. Declarative Scenarios
Given a clear database
And the database is loaded from "sample-data.sql"
And the webserver is running
When I go to URL: http://localhost:8080/myapp
And I click the "Login" link
And I enter username: john
And I enter password: john99
And I click the "Login" button
Then the page contains text: Hello John!
Background:
Given the following users:
| First Name | Last Name |
| John | Smith |
When John logs in
Then a greeting "Hello John!" is displayed.
14
15. Decouple, Reduce Noise, Focus on
Value
Given a clear database
When I create a user "John Smith" with login "jsmith"
When I login as "jsmith"
Then a greeting "Hello John!" is displayed.
Background:
Given the following users:
| First Name | Last Name |
| John | Smith |
When John logs in
Then a greeting "Hello John!" is displayed.
15
17. Challenges of UI Automation
• Technical
•Infrastructure Dependency (Speed, Stability …)
•Tests run in another Process
• Development Process
•80% of all changes are in the UI
• Tools can help:
•Mara, MVCContrib (“Capybara like”)
17
18. Organization of Features
Features are TODO: Screenshot
project artifacts:
•versioned in VCS
•Hierarchies
•Change over time TODO: Screenshot
18
19. Organizing Steps
• Steps are code
• Organize steps along domain
concepts. Avoid feature-
coupled steps
• Scoped steps
19
21. Outside-In Development
• Starting from the UI Layer is
difficult
•Start with a scribble / sketch
•Good conventions help (aka.
semantic markup) 1
•Progress step by step. Building 2
3
the UI incrementally 4
5
• Progressing to TDD
•Not always needed?
21
22. Improving Feedback with a
Transparent Development Process
Requirements Analysis
Executable & Automated
Specifications
Improving Feedback with a
Transparent Development Process
Living Documentation
22
23. Transparency
• Why?
•Trust, Feedback, Learning, Embracing Change
• Scrum Tools
•Standup, Taskboard, Burndown, Demo,
Retrospective
• How can BDD help to improve it?
•Technical Feedback
•Different Perspective
•Shared understanding
23
27. Living Documentation
Requirements Analysis
Executable & Automated
Specifications
Improving Feedback with a
Transparent Development Process
Living Documentation
32
28. Evolving the living documentation
Product Backlog Living Documentation
AccCrit 1 AccCrit 1
User Story 1
AccCrit 2 „Done“ AccCrit 2
Feature 1
AccCrit 3 AccCrit 3
User Story 2
AccCrit 4 AccCrit 5
AccCrit 5 AccCrit 4
User Story n Feature n
AccCrit m AccCrit m
• Units of work • Documentation
• Organized according to • Organized according to
priority/value/effort functionality/overview
• Versioned/maintained with
source code
33
29. Living documentation
Current sprint Features “done”
merge
when F
Sprint US accepted
US
Backlog AC F F
Acceptance
Criteria AC
US Acceptance
refine
AC
Criteria AC
AC
Acceptance the F F F
Criteria
US specification AC
Acceptance
Criteria
Acceptance
Criteria
F F
Acceptance
US Criteria
Acceptance AC AC
Criteria Given … {…} validate
Automation
AC AC
When … {…} continuously
AC living documentation
Then … {…}
specification with examples
validate
executable continuously
specification
34
