Boss? Beer? Buzzword?

What is B in BDD

Mirosław Pragłowski / @mpraglowski

Who is...


  • How many of you are already using BDD?
  • How many of you have heard of BDD?
  • How many of you are good at TDD?
  • Who is tester in your team?


Stack Overflow

TDD: 3423 & 1.4k followers

BDD: 1365 & 505 followers

at 9 April 2014


  • Open source tool for BDD in .NET
  • Focus on high level behavior: features & acceptance tests
  • Story-style plain text specifications
  • Using Gherkin as a DSL for defining specifications
  • Use existing testing frameworks for execution (NUnit, MSTest, xUnit)
  • Integration with dev’s tools (VisualStudio) & build servers (TeamCity)


using SpecFlow

You're doing it

Why ?

  1. Started by installing a tool
  2. Expected that customer could define test by himself
  3. Assumed that tests will be acceptance criteria
  4. ...
  5. In long term our test set will become a regression tests

BDD myths

by Gojko Adzic at NDC 2012 (@gojkoadzic)

MYTH #1:


Belief that process problems can be solved by installing a tool

MYTH #2:


Belief that business users should write acceptance tests

MYTH #2:

MYTH #3:


Belief that tests are either unit of acceptance-integration

MYTH #4:


<insert role> should do BDD in isolation (eg testers do everything)

MYTH #5:


Belief that the long term value of BDD is in regression testing

What BDD is not?

It is really BDD?

  • FALSE: BDD is a framework
  • FALSE: BDD is for defining system behavior
  • FALSE: BDD is for Business Applications
  • FALSE: BDD frameworks are for higher level, TDD for lower level components
  • FALSE: BDD frameworks are for end users to use
  • FALSE: BDD is for Integration Testing, TDD is Unit Testing

So, what the f**k is BDD?

Dan’s definition of BDD

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’s definition of BDD

BDD bach Cha’Dlch puq 
poH, Hur-baS ‘In, gher-
ejyo’waw’, Qln vagh-Sa’,
Qln vagh blm, jen-qoq,
Qincha’ tlhevjaQ.

translation by Gojko Adzic

BDD is unambiguous language for development process

Requirements defined by Feature

  • Is defined by User Story
  • User story has a title
  • User story has a narrative
    As a [role]
    I want [some feature]
    so that [reason]
  • User story has test scenarios
    Given [context]
    when [sth happen]
    then [some output]
  • Test scenarios are a definition of done

BDD it’s about communication

Typical process

  • Business Analyst tries to define system requirements
  • Requirements are defined as a set of features
  • Features are described in a form of user story
  • For each user story some test scenarios are prepared
  • User stories are implemented by developers
  • Completed features are tested by testers

Separation of roles

User Stories


Functional gaps



Specifying collaboratively

User Stories

Functional gaps
Misunderstood requirements



Unexpected stuff

BDD is living specification

What is TEST?

When it’s written is not a test, it is an example of something I don’t have yet, 
it’s a specification

by Dan North

What if test FAILS?

What if test FAILS?

It is not completed feature.

What if test FAILS?

It is not completed feature.

It is a missing specification!

Specification by example

  • Abstract requirements & specifications are not good tool for communication
  • Concrete examples are much better
  • Usually examples are not formalized nor shared

Specification by example

The key process patters of Specification by example (Gojko Adzic)

There is no silver bullet!

A few links...

Available at

Sample code