Specification By Example

using

Behavior Driven Development (BDD)

Created by Viktor Farcic & Jordi Falguera for Technology Conversations / @vfarcic / @jordi_falguera

Viktor Farcic

  • Software Architect at Defie
  • Never developed in Fortran
  • Passionate about TDD, BDD and Continuous Delivery
  • Blogger in TechnologyConversations.com
  • Java Test-Driven Development: Mastering TDD Through Katas

Index

Communication challenges

The telephone game

Communication challenges

Death by documentation

Communication challenges

Group Think effect

Communication challenges

BAs trying to answer directly

How can we bridge this gap?

Align all the stakeholders

How can we bridge this gap?

Use an ubiquitous language

How can we bridge this gap?

Communicate with examples

How can we bridge this gap?

Take advantage of black box testing

Specification By Example

Same shit with different names

  • ATDD (Acceptance Test Driven Development)
  • FTDD (Functional Test Driven Development)
  • BDD (Behavior Driven Development)
  • EDD (Examples Driven Development)
  • SBE (Specification By Example)
  • Executable Specifications

Specification By Example

Benefits

  • Improved communication
  • Shared understanding of the problem
  • Reduction in feedback loops
  • Examples being the Single Source of Trust
  • Easy to check whether the code conforms to the specs

Specification By Example

Frameworks

  • Fit (Framework for Integrated tests)
  • Fitnesse
  • JBehave / Cucumber / Specflow
  • Robot framework
  • Concordion

Behavior Driven Development (BDD)

Introduction

  • Agile process
  • Stakeholder value
  • Unique set of artifacts
  • TDD with clarity
  • Natural language
  • A way to get technical and non-technical people to understand each other

Behavior Driven Development (BDD)

Story

  • Narrative
  • One or more scenarios

Behavior Driven Development (BDD)

Narrative


                            Narrative:
In Order to [benefit]
As a [role]
I Want to [feature]

Behavior Driven Development (BDD)

Narrative

  • NOT requirement statements
  • Everyone can write them
  • INVEST
    • Independent
    • Negotiable
    • Valuable
    • Estimable
    • Small
    • Testable

Behavior Driven Development (BDD)

Scenario


                            Scenario: [description]
Given [context or precondition]
When [event or action]
Then [outcome validation]

Process

  • Write and discuss narrative
  • Write and discuss short descriptions of scenarios
  • Write steps for each scenario
  • Repeat steps 2 and 3 during the development of the narrative

Automation

Frameworks

  • JBehave (Java)
  • Cucumber (Ruby / Java / .Net / Flex)
  • RSpec (Ruby)
  • Spec Flow (.Net)

Automation

Steps

  1. Create library of normalized steps
  2. Combine steps into composites
  3. Empower scenarios with examples tables

Automation

Phase #1

Create library of normalized steps

  • Separate the scenarios from the code
  • Build the steps library
  • Create small atomic steps
  • Standardize steps format
  • Externalize parameters
  • Avoid repeated code with aliases

Automation

Phase #1

Create library of normalized steps

Separate the scenarios from the code
Java code:@When("user clicks the $id button")
public final void clickButton(final String id) {
    // Code that clicks the button with specified ID
}
BDD step:
When user clicks the login button

Automation

Phase #1

Create library of normalized steps

Build the steps library
CommonSteps - WebSteps        - MyWebSiteSteps
                              - BackOfficeSteps
            - DatabaseSteps   - OracleSteps
                              - MySQLSteps
                              - DB2Steps
            - APISteps        - JSONSteps
                              - WebServiceSteps
            - OperationsSteps - ShellSteps
                              - WindowsSteps
                              - TelnetSteps

Automation

Phase #1

Create library of normalized steps

Create small atomic steps
BDD story:
When visitor types john.doe@example.com into the email field
When visitor types password mysecret into the password field
When visitor clicks the register button

Automation

Phase #1

Create library of normalized steps

Standardize steps format
BDD story:
When Web user clicks the $id element
When Web user clicks the $id link
When Back office user clicks the $id button

Automation

Phase #1

Create library of normalized steps

Externalize parameters
BDD story:
Given Web user is using Firefox browser
Given Web user opened http://www.google.com
When Web user types behavior driven development in the search field
Then the first result is Behavior-driven development - Wikipedia
BDD Story:
Given Web user is using selected browser

Automation

Phase #1

Create library of normalized steps

Avoid repeated code with aliases
Java code@When("Web user clicks the $id element")
@Aliases(values={
    "Web user clicks the $id button",
    "Web user clicks the $id link"
}
public final void clickElement(final String id) {
    ...
}

Automation

Phase #2

Combine steps into composites

Automation

Phase #2

Combine steps into composites

Without composites
BDD story:
Given user is on the home screen
When user types john.doe@example.com into the email field
When user types my_secret into the password field
When user clicks the login button
Then confirmation screen is opened

Automation

Phase #2

Combine steps into composites

With composites
BDD story:
Given user is logged in
Java code:@Given("user is logged in")
@Composite(steps = {
    "Given user is on the home screen",
    "When user types john.doe@example.com into the email field",
    "When user types my_secret into the password field",
    "When user clicks the login button",
    "Then confirmation screen is opened"
}

Automation

Phase #3

Empower scenarios with examples tables

Scenario: Visitors are able to register

Given visitor is on the registration screen
When visitor types email <email>
When visitor types password <password>
When visitor clicks the register button
Then text <text> is displayed

Examples:
|email                |password |text                            |
|john.doe@example.com |mysecret |Welcome john.doe@example.com    |
|john.doe@example.com |secret   |Password is too short           |
|john.doe             |mysecret |Email is incorrect              |

BDD vs TDD

  • Similar but not the same
  • BDD eliminates issues that TDD might cause
  • BDD works best when used together with TDD

BDD vs TDD

What is TDD?

Red-Green-Refactor

  1. Write a test
  2. Run the test
  3. Write the implementation code
  4. Run the test
  5. Refactor

BDD vs TDD

Similarities

  • Both drive software development
  • Both write specification before the implementation
  • Both are replacing part of existing documentation

BDD vs TDD

Differences

  1. BDD is readable by non-geeks
  2. Specification and behaviour vs code design and units
  3. Many vs one (or two in case of Pair Programming)
  4. Time span between specification and implementation
  5. Levels of abstraction
  6. Behavior vs code
  7. BDD is acceptance criteria
  8. Everyone vs coders

BDD & Continuous Delivery

Introduction

  • Commit to VCS
  • Static analysis
  • Unit tests
  • Functional and integration tests
  • Package & deliver

BDD & Continuous Delivery

Functional Tests vs BDD

  • What we expect vs what users expect
  • Tests vs executable requirements
  • Tests vs acceptance criteria

BDD Assistant

More information on the site and in the repository.

Q&A

Additional Information

The End

By Viktor Farcic & Jordi Falguera

@vfarcic @jordi_falguera

technologyconversations.com