Jonas Bandi Gaspar Nagy

http://blog.jonasbandi.net http://gasparnagy.blogspot.com
jonas.bandi@techtalk.ch gaspar.nagy@techtalk.at
twitter: @jbandi twitter: @gasparnagy
BDD?
BDD? – BUSHIDO DRIVEN DEVELOPMENT

Write good
code or kill
yourself out
of shame.
@durp
Boss Driven
Development

Beer Driven
Development
 Ah ok... I understand. It is done!"

BDD? – What? What do you mean?"

BUG DRIVEN Well it is done. The system is finished!

Well, no ... I don't see an icon where I can start it?

DEVEL- I want you to build an Instant Social Turbo
Oh! You are right. That's a bug! I will fix it!
OPMENT Communication Workstation Terminal
... five minutes later ...
Ok, the icon is here. Now it is done!

But when I double-click the icon nothing happens!

Oh! You are right. That’s a bug! I will fix it.

... five minutes later ...

Ok, the app starts when you double click. Now
it is done!"
 BDD –
Behavior Driven
Development
 ABOUT US

Jonas Bandi Gáspár Nagy

TechTalk TechTalk
Committer to SpecFlow Committer to SpecFlow
http://blog.jonasbandi.net http://gasparnagy.blogspot.com
Twitter: @jbandi Twitter: @gasparnagy

TechTalk is a software development and

consulting company with ~60 people
located in Vienna, Budapest and Zürich. The research is partially supported by
the project of Eötvös Loránd University:
We focus on Scrum and .NET. TÁMOP-4.2.1.B-09/1/KMR-2010-0003
 THE AUDIENCE?
 Who is practicing agile Development?
 Who is practicing TDD?
 Wo is doing Acceptance Test Driven
Development or Behavior Driven
Development?
 Wo is using Cucumber, Fitnesse,
Concordion, NBehave or a similar
tool?
 Who knows SpecFlow?
 AGENDA

 The Communication Gap: A reason why

we are failing
 Agile software development: promissed
improvement
 BDD as a possible approach to improve
 SpecFlow as a tool that supports BDD
 Demo
 Once upon a
time...

... in the golden

Age of the
Waterfall.
… and they lived happily ever after!
Welcome to the real world!
... the golden age is over!
 WHAT DID REALLY CHANGE?

2000 2008
Project success, Chaos Report, Standish Group
 What
Why is the
does problem?
software fail?
Therac-25, radiation therapy machine (1985)
"I believe that the hardest
part of software projects,
the most common source
of project failure, is
communication with the
customers and users of
that software."
- Martin Fowler, DSL Book
WHAT DEFINES SUCCESSFUL SOFTWARE?

Software development is about

delivering business value!
WHAT IS BEING USED?

CHAOS Report 2000, Standish Group

We produce software
that is not used!
WHERE ERRORS ARE INTRODUCED

Source: James Martin, An Information Systems Manifesto

 FIGHTING ERRORS?

• Traditional developer testing

focuses on code and maybe
design
• Testing requirements is hardly
ever a topic
• We can profit tremendously
when we improve in
requirements gathering.
PROBLEMS WITH REQUIREMENTS?
WATERFALL
 ABSTRACTION DURING ANALYSIS
Project Why?
success
Why?
Vision
,,Value”
Business Goals

Ressources Rough Specification

Level of Detail
What? Detail Specification
,,Scope”

Communication
Gap!
Realization

How?
,,Details” Code

How?
Predictability Quantity
ABSTRACTION DURING ANALYSIS
THE TRADITIONAL APPROACH
TELEPHONE GAME

http://www.brokenpicturetelephone.com
 TELEPHONE GAME

“Engineers are not good at dealing with Customers”

- Office Space
Agile to the rescue!
ITERATIVE DEVELOPMENT
 STREAMING REQUIREMENTS

 Not all of the requirements

are delivered upfront
 Requirements are delivered
just in time
 Incrementally reveal details
just-in-time
 Pull instead of push
 Embrace Change
 THE PROMISED BENEFITS

 Constant feedback and priorization

by the Stakeholder
 Build those features that are needed
and useful

 Features have a much shorter

through-put time
 Allows validation of requirements
 REMAINING CHALLENGES

 How to communicate requirements

effectively?
 How to ensure that requirements are
understood and implemented
correctly?
 REQUIREMENTS == TESTS
As formality increases, tests
and requirements become
indistinguishable. At the limit,
tests and requirements are
equivalent.
Equivalence Hypothesis (Martin,
Melnik, 2008)

 Executable test-based
specifications
Pic: Martin/Melnik: Requirements and
Tests
BDD?
 BDD – A DEFINITION FROM 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
 BDD: AN ATTEMPT TO FIT IT ALL TOGETHER
Specification by
TDD Example
Test Driven Development Definition of
Done
DDD
Domain Driven Design BDD ATDD
Behavior Driven Acceptance Test Driven
DSL Development Development
Domain Specific Language

Outside-In User Stories

Development
TDD
ATDD: RISING THE LEVEL OF
ABSTRACTION
 OUTSIDE-IN DEVELOPMENT

 Always start with a Story

 What development should
focus on: 1

 Providing business value 2

3
 Satisfying stakeholder needs 4
5
 Software that matters
 Consumable software
 THE REAL GOAL

 Test Driven Development is about

Design
 Acceptance Test Driven Development
is about Specification
 Writing acceptance tests early
 is a requirements engineering
technique
 builds a common understanding
 defines clear goals and a common
definition of done
Pic: http://www.projectcartoon.com/
 DETAIL DISCUSSIONS…
We want to encourage new users to place an order.
Therefore we are going to offer 10% discount on
every initial order.

public void TestInitialOrderDiscount() Register as “bart_bookworm”

{ Go to “/catalog/search”
Customer newCustomer = new Customer(); Enter “ISBN-0955683610”
Order newOrder = new Order(newCustomer); Click “Search”
newOrder.AddBook(
Catalog.Find(“ISBN-0955683610”)
Click “Add to Cart”
); Click “View Cart”
Assert.Equals(33.75, Verify “Subtotal” is “$33.75”
newOrder.Subtotal);
}
 ACCEPTANCE CRITERIA
Why?

Business Goals
 Formalized
 Concrete and Actor-Goals

Level of Detail
Epics
consistent
User Stories

Communication
 Verifiable

Gap!
Acceptance
Bugs
 Up-to-date Criteria

 Just in time
Code

How?
Predictability Quantity
 EXAMPLE: USER STORIES
Why?

As a potential customer
I want to search for books by a simple string
So that I can easily allocate books by somethingBusiness
I Goals

remember from them.

Actor-Goals

Level of Detail
Epics

As a potential customer User Stories

Communication
I want to place books into my shopping basket

Gap!
So that I can order several books at once. Acceptance
Criteria

Code

How?
Predictability Quantity
 EXAMPLE: ACCEPTANCE CRITERIA
Why?

As a potential customer
I want to place books into my shopping basket
So that I can order several books at once. Business Goals

Actor-Goals

Level of Detail
Epics
Books can be added to basket.
User Stories

Communication
Basket should be empty initially.

Gap!
Acceptance
Criteria
Books can be removed from basket.

Adding same book increases quantity.

Code

How?
Predictability Quantity
 SPECIFICATION BY EXAMPLE
• Abstract requirements and
specifications are not a good tool for
communication.
• Concrete examples are much better.
• Usually examples are not formalized
and not shared.
are composed of
Examples Tests
elaborate verify & validate

Requirements
 EXAMPLES AS ACCEPTANCE CRITERIA
As a potential customer
I want to place books into my shopping basket
So that I can order several books at once.

Books can be added to basket.

Given I have an empty basket

When I add the book “Harry Potter” to my basket

Then there should be 1 copy of “Harry Potter” in my basket

 EXAMPLES AS ACCEPTANCE CRITERIA
As a potential customer
I want to place books into my shopping basket
So that I can order several books at once.

Books can be added to basket.

Adding same book increases quantity.

Given I have a basket which contains 1 copy of “Harry Potter”

When I add the book “Harry Potter” to my basket

Then there should be 2 copies of “Harry Potter” in my basket

 STRUCTURE OF EXAMPLES
Title: Describes Intention/abstract acceptance criteria
Arrange: prepares prerequisites
Triple-A
Act: exercises the feature
constraint
Assert: verifies results “Checks”
Adding same book increases quantity.

Given I have a basket which contains 1 copy of “Harry Potter”

When I add the book “Harry Potter” to my basket

Then there should be 2 copies of “Harry Potter” in my basket

Chaining
And my basket should contain 2 items in total steps
 DETAIL DISCUSSIONS…
We want to encourage new users to place an order.
Therefore we are going to offer 10% discount on
every initial order.

public void TestInitialOrderDiscount() Register as “bart_bookworm”

{ Go to “/catalog/search”
Customer newCustomer = new Customer(); Enter “ISBN-0955683610”
Order newOrder = new Order(newCustomer); Click “Search”
newOrder.AddBook(
Catalog.Find(“ISBN-0955683610”)
Click “Add to Cart”
); Click “View Cart”
Assert.Equals(33.75, Verify “Subtotal” is “$33.75”
newOrder.Subtotal);
}
 … ILLUSTRATED WITH EXAMPLES

Given a user who hasn't placed an order yet

When the user puts a book into the shopping cart

Then a discount of 10% should be applied on the cart total.

 SHOW IMPLICIT EXPECTATIONS
Actually, this is not quite right:
books on sale should be excluded from
discount.
 3 AMIGOS
Exceptional,
Happy
Feasibility Edge Cases
Path
 EXAMPLES

• Enable developers and testers to communicate

efficiently with business people
• Provide enough information for developers to
implement and for testers to verify
• Realistic examples contain precise information
and ask for precise answers
• Are a way to test specifications!
• … express a shared understanding
 BDD: AN ATTEMPT TO FIT IT ALL TOGETHER
Specification by
TDD Example
Test Driven Development Definition of
Done
DDD
Domain Driven Design BDD ATDD
Behavior Driven Acceptance Test Driven
DSL Development Development
Domain Specific Language

Outside-In User Stories

Development
 REMEMBER

BDD is a Mindset not a Tool!

 LITERAL AUTOMATION
Definition of Done
+ Automation
= Executable Specification

Given I have a basket which contains 1 copy of “Harry Potter” Binding

When I add the book “Harry Potter” to my basket

Then there should be 2 copies of “Harry Potter” in my basket

UI
System
Automation
Automation
Schnittstelle
 SPECFLOW
 Open-source BDD tool for .NET
 www.specflow.org
 github.com/techtalk/SpecFlow

 Focus on high level behavior: features /

acceptance tests
 Focus on story-style plain text specifications
 Using Gherkin as DSL for specifications
 Uses existing testing frameworks for
execution (Nunit, MSTest, xUnit)
 VisualStudio / Build integration
www.specflow.org
 SPECFLOW HISTORY
 SpecFlow was founded in late 2009 by
TechTalk
 Goals:
 A pragmatic BDD tool for .NET
 Provide a frictionless experience for .NET
environments
 Use existing tools: VisualStudio, UnitTest-
Frameworks
 SpecFlow is used in several projects
by TechTalk www.specflow.org
 GHERKIN
 A language (DSL) for story-style plain
text specifications
 “Given“-“When“-“Then“
 Rooted in the Ruby World: Cucumber
 Business readable / writeable
 Sufficient formality
 Enable automation
 Executable specification

www.cukes.info
 http://github.com/aslakhellesoy/gherkin/
GHERKIN EXAMPLE
 GHERKIN KEYWORDS
 Feature
 Scenario
 Given,When,Then,And,But
 Background
 Scenario-Outline, Examples

 Event Hooks (Before-, After- / -Feature, -Scenario, -ScenarioBlock, -Step)

 Table Arguments
 Tags
DEMO
HOW SPECFLOW WORKS
LIVING DOCUMENTATION
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
 AUTOMATED SCENARIOS …

 … describe what the system should do

 … are business readable
 … establish a common vocabulary
 … capture a shared set of examples
 … enable communication
 … are bound to the implementation
 … are executable
 … express a shared understanding
 SUMMARY
 Deriving scope from goals
 Increase level of detail just-in-time
 Specifying details by example
 Collaboration of the „3 amigos“
 Outside-in, TDD, DDD
 Living documentation
 Literal automation
 Continuous validation
BOOKS
BDD TOOLS
 SIMILAR TOOLS IN THE .NET SPACE
Plain-Text specifications: Context/Specification Tools:
 Cucumber via IronRuby • MSpec
www.cukes.info http://github.com/machine/machine.specifications

 Cuke4Nuke
http://github.com/richardlawrence/Cuke4Nuke/
• BDD extension for xUnit
 NBehave http://code.google.com/p/xunitbddextensions/
http://nbehave.org/

 Fit/Fitnesse
http://nbehave.org/

 StorEvil
http://wiki.github.com/davidmfoley/storevil/
• Nspec
 StoryQ http://nspec.tigris.org/
http://storyq.codeplex.com/

 Specter • SpecUnit.Net
http://code.google.com/p/specunit-net/
http://specter.sourceforge.net/

 Aubergine
github.com/ToJans/Aubergine
 GHERKIN TOOLS

 Cuke4Vs
http://github.com/henritersteeg/cuke4vs
 Gherkin Editor
http://gherkineditor.codeplex.com/

 NetBeans Plugin
 JetBrain RubyMine
 TextMate Bundle
 Vim integration
 MORE INFO
 www.specflow.org
 http://github.com/techtalk/SpecFlow
 http://github.com/techtalk/SpecFlow-Examples
 http://groups.google.com/group/specflow/
 http://wiki.github.com/aslakhellesoy/cucumber/
 http://tekpub.com/view/concepts/5
 http://blog.stevensanderson.com/2010/03/03/behavior-driven-
development-bdd-with-specflow-and-aspnet-mvc/
 http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspx
 http://bitbucket.org/rstuven/steckbrett.specssupport/src

TechTalk offers:
 Workshops for:
 Agile Requirements Analysis
 Implementing BDD
FRAGEN UND DISKUSSION