This document discusses behavior driven development (BDD) and the use of SpecFlow, an open source BDD tool for .NET. It begins by explaining some of the communication problems that can occur in traditional waterfall software development approaches. It then introduces BDD as a way to improve communication through the use of examples and acceptance criteria specified in a shared language like Gherkin. SpecFlow is presented as a tool that supports BDD for .NET projects by allowing executable specifications to be written in Gherkin and linked to test frameworks. The document demonstrates SpecFlow and discusses how it helps automate scenarios to establish a common understanding and ensure requirements are properly implemented.

1. .NET
User
Group
Bern
Jonas Bandi
http://blog.jonasbandi.net
jb@jonasbandi.net
twitter: @jbandi

2. DNUG Bern Sponsoren

3. High quality technical screencasts created by
experts on the latest and most important
technologies. Buy access to a single series or
subscribe for as little as $19 a month.
tekpub.com
ASP.NET MVC
Ayende Rahien
Rob Conery
jQuery
Dave Ward
Ruby on Rails
ASP.NET Ajax
LINQ
nHibernate

4. About me
TechTalk is a software
development and consulting
company with ~60 people located
in Vienna, Budapest and Zürich.
We focus on Scrum and .NET.
Jonas Bandi
At TechTalk since 2009
Committer to SpecFlow
http://blog.jonasbandi.net
Twitter: @jbandi

5. 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?

6. Agenda
• The Communication Gap: A reason why
we are failing
• Agile software development promises
improvement
• BDD as a possible approach to improve
• SpecFlow as tool that supports BDD
• Advanced topics and loose ends

7. Let´s discuss!
"We're still figuring
this stuff out.
All of us."
- Jay Fields
Thoughts on developer Testing:
http://blog.jayfields.com/2009/02/thoughts-on-developer-testing.html

8. Once upon a
time...
... in the golden
Age of the
Waterfall.

9. … and they lived happily ever after!

10. Welcome to the real world!

11. ... the golden age is over!

12. What did really change?
Project success, Chaos Report, Standish Group
2000 2008

13. What is the problem?

14. "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

15. What defines successful software?
Software development is about
delivering business value!

16. What is being used?
CHAOS Report 2000, Standish Group

17. Providing Business Value?
• Only 20% of all delivered features are
actually used?
• Something is wrong!
• We can profit tremendously when we
improve in
• requirements gathering
• transporting them successfully to the
implementation

18. Where errors are introduced
Source: James Martin, An Information Systems Manifesto

19. 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.

20. Problems with requirements?

21. Waterfall

23. _
Abstraction during Analysis
Level
of
Detail
Why?
How?
Rough Specification
Rough Specification
Business Goals
Business Goals
Why?
,,Value”
What?
,,Scope”
How?
,,Details”
Project
success
Ressources
Realization
Quantity
Predictability
Code
Vision
Vision
Detail Specification
Detail Specification
Communication
Gap!

24. Abstraction during Analysis

25. The Traditional Approach

26. Telephone Game
http://www.brokenpicturetelephone.com

27. Telephone Game
“Engineers are not good at dealing with Customers”
- Office Space

28. Agile to the rescue!

29. Iterative development

30. 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

31. 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

32. Remaining challenges
• How to communicate requirements
effectively?
• How to ensure that requirements are
understood and implemented correctly?

33. 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

34. Behavor Driven Development:
An attempt to fit it all together
BDD
Behavior Driven
Development
TDD
Test Driven Development
DDD
Domain Driven Design
ATDD
Acceptance Test Driven
Development
User Stories
Specification
by Example
Definition of
Done
Outside-In
Development
DSL
Domain Specific Language

35. TDD

36. ATDD: Rising the Level of
Abstraction

37. The real Goal
Pic: http://www.projectcartoon.com/
• Test Driven Development is about
Design
• Acceptance Test Driven
Development is about
Specification and Communication
• Writing acceptance tests early
– is a requirements engineering
technique
– builds a common understanding
– defines clear goals and a
common definition of done

38. 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.
Examples Tests
Requirements
are composed of
elaborate verify & validate

39. _
Agile Analysis
Level
of
Detail
Why?
How?
Actor-Goals
Actor-Goals
Epics
Epics
Business Goals
Business Goals
User Stories
User Stories
Acceptance
Acceptance
Criteria
Why?
,,Value”
What?
,,Scope”
How?
,,Details”
Project
success
Ressources
Realization
Quantity
Predictability
Code
Communi-
cation
Gap!
Vision
Vision

40. _
Example: User Stories
Detailgrad
Why?
How?
Actor-Goals
Actor-Goals
Epics
Epics
Business Goals
Business Goals
User Stories
User Stories
Acceptance
Acceptance
Criteria
Amount of Work
Predictability
Code
As a potential customer
I want to search for books by a simple string
So that I can easily allocate books by
something I remember from them.
As a potential customer
I want to place books into my shopping basket
So that I can order several books at once.
Communi-
cation
Gap!

41. _
Example: Acceptance Criteria
Detailgrad
Why?
How?
Actor-Goals
Actor-Goals
Epics
Epics
Business Goals
Business Goals
User Stories
User Stories
Acceptance
Acceptance
Criteria
Amount of Work
Predictability
Code
As a potential customer
I want to search for books by a simple string
So that I can easily allocate books by
something I remember from them.
Author of book should be matched.
Space should be treated as multiple OR search.
Search string should be at least 4 characters.
Items should be matched only once.
Title of book should be matched.
Communi-
cation
Gap!

42. Examples as Acceptance Criteria
As a potential customer
I want to search for books by a simple string
So that I can easily allocate books by
something I remember from them.
Title of book should be matched.
Given the following books
| Author | Title |
| Ted Pattison | Inside Windows SharePoint Services |
| Martin Fowler| Patterns of Enterprise Architecture |
| Eric Evans | Domain Driven Design |
When I perform a simple search on “Domain”
Then the book list should only contain: “Domain Driven Design”

43. 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

44. Building a shared understanding

45. Shared understanding
• Terminology and
abstractions of business
• Concrete enough for
developers
• Business readable
• Bound to implementation
• Consistent

46. Outside-In Development
• Always start with a Story
• What development
should focus on:
– Providing business value
– Satisfying stakeholder
needs
– Software that matters
– Consumable software
1
2
3
4
5

47. Behavor Driven Development:
An attempt to fit it all together
BDD
Behavior Driven
Development
TDD
Test Driven Development
DDD
Domain Driven Design
ATDD
Acceptance Test Driven
Development
User Stories
Specification
by Example
Definition of
Done
Outside-In
Development
DSL
Domain Specific Language

48. Remember
BDD is a Mindset not a Tool!

49. BDD Tools: Automation
Definition of Done
+ Automation
= Executable Specification

50. 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

51. 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

52. 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
• http://github.com/aslakhellesoy/gherkin/ www.cukes.info

53. Gherkin Example

54. Gherkin Keywords
• Feature
• Scenario
• Given,When,Then,And,But
• Background
• Scenario-Outline, Examples
• Event Hooks (Before-, After- / -Feature, -Scenario, -ScenarioBlock, -Step)
• Table Arguments
• Tags

55. Gherkin Features
• User stories are
requirements
• A single scenario is an
example that drives the
development
• Scenarios define a common
definition of „done“
• All scenarios together build
the acceptance criteria of
the story/feature

56. How SpecFlow works

57. Demo

58. 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

59. Advanced Topics

60. Acceptance Tests vs. Unit Tests
• Acceptance Tests
• Business oriented
• What?
• Are we building the right
thing?
• Unit-Tests
• Code oriented
• How?
• Are we building it right?
Picture: RSpec Book

61. Internal vs. External Quality

62. Behavior Specifications are
Examples
• Demonstrating each important aspect
of a system
– Standard cases
– Edge cases
– Critical areas
• The main goal is not a full regression
– However the artifacts of automated examples
can be reused for regression testing

63. Agile Testing Quadrants
• Agile Testing is more than QA
– Not only detect bugs
– Improve quality by preventing bugs …

64. Testing Pyramid
• Automation allows more resources for
„valuable“ testing activities
Test
Automation
Pyramid
by
Mike
Cohn

65. Different Access Levels
• UI
• Just below the UI
• Application
Services
• In the domain

66. Accessing the App through the UI
• Full end-to-end test
• Driving the UI adds a lot
of accidental complexity
and noise
– Structure of resulting UI is not
clear from the beginning
– Widget selection (CSS-
Selectors, byId …)
– It is hard to drive functionality

67. Accessing the App just below the UI
• Establish an Architecture
where you can access the
Application just below the UI
– Design for Testability
– PassiveView, ViewModel,
Controller
• Provide an abstraction and a
programmatic API that allows
driving functionality
• The last step has to be
tested by QA
– manually or scripted

68. Accessing the App through
Application Services
• Core business functionality
often resides in
encapsulated modules
• Drive functionality from the
interface of a module
– Gap between scenario and
implementation grows
– Reliability of a passing scenario
diminishes
• Good example: „Classic“
SOA

69. Accessing the Domain
• Core business functionality
often resides in a domain
model
• It is possible to bind a
scenario directly to the
domain
– Gap between scenario and
implementation is big
– Danger of leaking too many details
into the scenarios („programming in
plain-text“)
– Usually better suited for unit-tests

70. It is a trade-off
outside-in,
efficiency, speed
end-to-end
integration
vs.

71. Stubbing
• Stubbing helps to isolate the feature
– Better for driving the development
– Worse for testing the application

72. Books

73. BDD Tools

74. History of BDD
• 2001: Dan North
invented the term
• JBehave (Java)
• RSpec (Ruby)
• Cucumber (Ruby)
„where the hype is today…“
„TDD is not
about
Testing“
„BDD is a
Development
Methodology“
Code-Focused,
Unit-Behavior
Feature-Focused,
System-Behavior

75. Similar tools in the .NET space
Plain-Text specifications:
• Cucumber via IronRuby
www.cukes.info
• Cuke4Nuke
http://github.com/richardlawrence/Cuke4Nu
ke/
• NBehave
http://nbehave.org/
• Fit/Fitnesse
http://nbehave.org/
• StorEvil
http://wiki.github.com/davidmfoley/storevil/
• StoryQ
http://storyq.codeplex.com/
• Specter
http://specter.sourceforge.net/
• Aubergine
github.com/ToJans/Aubergine
Context/Specification Tools:
• MSpec
http://github.com/machine/machine.specificat
ions
• BDD extension for xUnit
http://code.google.com/p/xunitbddextensions/
• Nspec
http://nspec.tigris.org/
• SpecUnit.Net
http://code.google.com/p/specunit-net/

76. Gherkin tools
• Cuke4Vs
http://github.com/henritersteeg/cuke4vs
• Gherkin Editor
http://gherkineditor.codeplex.com/
• NetBeans Plugin
• JetBrain RubyMine
• TextMate Bundle
• Vim integration

77. 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/BddWithSpec
Flow.aspx
• http://bitbucket.org/rstuven/steckbrett.specssupport/src
TechTalk offers:
• Workshops for:
– Agile Requirements Analysis
– Implementing BDD

78. TechTalk Schweiz sucht Mitarbeiter!
TechTalk ist eine Entwicklungsfirma mit ca. 60 Mitarbeiter in
Wien und Budapest und Zürich. Wir fokussieren auf die .NET
Plattform und auf Scrum.
Wir suchen erfahrene Entwickler für den Aufbau des Standorts
Schweiz:
• Mehrjährige Erfahrung in diversen Projekten, idealerweise in
unterschiedlichen Branchen
• Grosse Flexibilität, Eigeninitiative und Selbstmotivation
• Erfahrung und Bereitschaft für On-Site Einsätze bei Kunden
Wir bieten:
• Aufbau eines jungen Unternehmens in einem kleinem Team
• Möglichkeit eines Aufenthaltes in Wien / Budapest
• Weiterbildung und Verwirklichung eigener Ideen
jobs@techtalk.ch

79. Fragen und Diskussion