• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introduction to Behaviour Driven Development
 

Introduction to Behaviour Driven Development

on

  • 2,608 views

A short introduction to Behaviour Driven Development.

A short introduction to Behaviour Driven Development.

Statistics

Views

Total Views
2,608
Views on SlideShare
2,607
Embed Views
1

Actions

Likes
5
Downloads
101
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Own experience: unclear specs!Valid also for ”traditional teams”, though made clearer for agile teamsBehaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on
  • This, then, is the role of a Story. It has to be a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is “done”. This is a more rigorous definition than in other agile methodologies, where it is variously described as a “promise of a conversation” or a “description of a feature”. (A BDD story can just as easily describe a non-functional requirement, as long as the work can be scoped, estimated and agreed on.)

Introduction to Behaviour Driven Development Introduction to Behaviour Driven Development Presentation Transcript

  • BDD
    Behaviour Driven Development (BDD)
    The 10 minutes Introduction
    Christophe Achouiantz – June 2011
  • The need for BDD
    Most common impediment for an agile team:
    Unclear Specifications!
    Christophe Achouiantz – June 2011
    2011-06-22
    Sida 2
  • BDD
    2006 – Dan North
    ”TDD/ATDD done well”
    “TDD will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software.”
    Test Driven Development – TDD
    Acceptance Test Driven Developement -ATDD
    2011-06-22
    Sida 3
    Christophe Achouiantz – June 2011
  • BDD is about Business Value
    Behaviour
    Driven
    Development
    2011-06-22
    Sida 4
    Christophe Achouiantz – June 2011
  • An ”Outside-in” methodology
    BDD is an “outside-in” methodology.
    Starts at the outside by identifying business outcomes,
    and then drills down into the feature set that will achieve those outcomes.
    2011-06-22
    Sida 5
    Christophe Achouiantz – June 2011
  • The Core of BDD: the ”Story”
    Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.
    BDD ”Story” =
    Narative (User Story) +
    Acceptance Criteria (Scenarios)
    2011-06-22
    Sida 6
    Christophe Achouiantz – June 2011
  • The Narative: User Stories
    User Story as narative (context)
    User centric
    Focus on What not so much How
    Contains sufficient information so that all stakeholders understand the context (who, when, what, why)
    2011-06-22
    Sida 7
    Christophe Achouiantz – June 2011
  • The Narative: User Stories
    + Title of the Story +
    As a <role>,
    I want <feature>,
    So that <benefit>
    2011-06-22
    Sida 8
    Christophe Achouiantz – June 2011
  • The Narative: User Stories
    + Customer withdraws cash +
    As a customer,
    I want to withdraw cash from an ATM,
    so that I don’t have to wait in line at the bank.
    2011-06-22
    Sida 9
    Christophe Achouiantz – June 2011
  • The Acceptance Criteria: Scenarios
    A UserStory’sbehaviour is itsacceptancecriteria
    Acceptancecriteriadefine the scope of the narative/behaviour
    Acceptance criteria gives us a shared definition of “done”
    2011-06-22
    Sida 10
    Christophe Achouiantz – June 2011
  • The Acceptance Criteria: Scenarios
    + Scenario Title +
    Given <context>,
    When <event>,
    Then <outcome>
    2011-06-22
    Sida 11
    Christophe Achouiantz – June 2011
  • The Acceptance Criteria: Scenarios
    +Scenario 1: Account is in credit+
    Given the account is in credit
    And the card is valid
    And the dispenser contains cash,
    When the customer requests cash,
    Then ensure the account is debited
    And ensure cash is dispensed
    And ensure the card is returned.
    2011-06-22
    Sida 12
    Christophe Achouiantz – June 2011
  • The Acceptance Criteria: Scenarios
    +Scenario 2: Account is overdrawn past the overdraft limit+
    Given the account is overdrawn
    And the card is valid,
    When the customer requests cash,
    Then ensure a rejection message is displayed
    And ensure cash is not dispensed
    And ensure the card is returned.
    2011-06-22
    Sida 13
    Christophe Achouiantz – June 2011
  • The Power of Scenarios
    Scenarios
    =
    Test Cases
    =
    Acceptance Criteria
    2011-06-22
    Sida 14
    Christophe Achouiantz – June 2011
  • A Good Story
    The title should describe an activity
    The narrative should include a role, a feature and a benefit
    The scenario title should say what’s different
    The scenario should be described in terms of Givens, Events and Outcomes
    The givens should define all of, and no more than, the required contextThe event should describe the feature
    The story should be small enough to fit in an iteration
    2011-06-22
    Sida 15
    Christophe Achouiantz – June 2011
  • Effect of BDD: A Specification and Ubiquitous Language
    BDD Story
    Great for discussing with customer, end-users, other stakeholders
    Great for coding, testing, validation
    = Specification (by example)
    + Promotes an Ubiquitous Language (everyone speaks the same language!)
    2011-06-22
    Sida 16
    Christophe Achouiantz – June 2011
  • BDD is relying on Examples
    ”Specification by Example”
    Examples tell a story about what the system does
    Gojko Adzic
    By the way:
    TDD is then more ”Coding by Example”
    Examples tell a story about what the code does
    2011-06-22
    Sida 17
    Christophe Achouiantz – June 2011
  • BDD in Practice
    Better requirements workshops / User Stories writing workshops
    Iterative work – clarify requirements:
    Write user story + scenarios
    Re-write user story (break down?)+ scenarios
    Helps to understand ”What do we want?”
    ”Aha!” reaction from participants
    Helps to write clear, concrete requirements
    2011-06-22
    Sida 18
    Christophe Achouiantz – June 2011
  • BDD Tools
    Automate your Scenarios!
    Frameworks for:
    Java - JBehave
    .Net - SpecFlow
    Ruby – Cucumber
    Others…
    2011-06-22
    Sida 19
    Christophe Achouiantz – June 2011
  • BDD Tools: Cucumber (Ruby)
    2011-06-22
    Sida 20
    Christophe Achouiantz – June 2011
  • Starting with BDD
    Use Scenarios during your next requirement writing workshop!
    2011-06-22
    Sida 21
    Christophe Achouiantz – June 2011
  • Happy BDD!
    2011-06-22
    Sida 22
    Christophe Achouiantz – June 2011