Behavior-Driven Development in ContextALEXANDER KRESS

TORONTO AGILE AND SOFTWARE 2014

About meDevelopment manager at

Worked with BDD based process for 5 years

Blog devmngr.wordpress.com

Twitter @al3xkress

The sales pitchBDD is a natural addition to an Agile process

BDD enhances communication in an agile group

BDD leads to fewer bugs and misunderstandings

BDD is easy to introduce and understand

Lots of open source tools exists to support a BDD roll out

Mанифест“Аджаил”-манифест разработки программного обеспечения

Люди и взаимодействие важнее процессов и инструментовРаботающий продукт важнее исчерпывающей документацииСотрудничество с заказчиком важнее согласования условий контрактаГотовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

ManifestoManifesto for Agile Software Development

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Common languagePO Dev QA

BDD in Context

From User Stories to BDD

The user story

As a Twitter user I would like to be able to post status updates In order to alert my followers to my latest doings

How would you break this up?

Let’s add TDDAdd a test

Run all tests and see if the new one fails

Write some code

Run the automated tests and see them succeed

Refactor code

Repeat

Writing tests is hardTo consider:

Which parts of the story do we want to test?

How do we structure test names to make them readable?

Would specific keywords in test names better define what they do?

What if we stopped thinking about tests and start thinking about behaviors?

Behavior-Driven Development

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agilemethodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Dan North

Also see http://dannorth.net/introducing-bdd/

BDD in Context

Nuts and Bolts

Gherkin – the languageFeature: Some terse yet descriptive text of what is desired In order to realize a named business value.

Scenario: Some determinable business situation

Given some precondition

And some other precondition

When some action by the actor

And some other action

And yet another action

Then some testable outcome is achieved

And something else we can check happens too

Behat documentation

Step

Body

Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor

Scenario: Getting into an elevator from the ground floor

GivenAnd

WhenAndAnd

ThenAnd

Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor

Scenario: Getting into an elevator from the ground floor

Given No Elevator is present on the ground floor

And An elevator has not been requested

And Elevator A is not moving, currently at floor 2

And Elevator B is going up, currently at floor 5

When I press the up button

Then Elevator A gets the call

And Elevator A arrives on the ground floor and opens doors

Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor

Scenario: Getting into an elevator from the ground floor

Given [No] Elevators are present on the [ground] floor

And An elevator has not been requested

And Elevator [A] is not moving, currently at floor [2]

And Elevator [B] is going up, currently at floor [5]

When I press the [up] button

Then Elevator [A] gets the call

And Elevator [A] arrives on the [ground] floor and opens doors

From Gherkin to CodeJava

Ruby

Python Lettuce --->

PHP

JavaScript

and many others API

From Gherkin to Code

BDD Step: Elevator A gets the call

BDD Framework: ElevatorAPI.callElevator(ground level, direction up);

BDD Framework: If(Not ElevatorAPI.callAcknowledged(ground level))

Throw new Exception(“Elevator not called”);

BDD Step: I press the [up] button

DemoFeature: User status update

Scenario: Normal flow, user is able to login and post a status update

Given I go to "www" with url "/"

And I fill in element "//*[@id='signin-email']" with value "agiledemo"

And I fill in element "//*[@id='signin-password']" with value

"demoagile"

And I click element "//*[@id='front-

container']/div[2]/div[2]/form/table/tbody/tr/td[2]/button"

And I verify current url path is "/"

And I verify text present "AgileDemo"

And I verify text present "@agiledemo"

And I ensure text not present "Writing a BDD presentation"

When I fill in element "//*[@id='tweet-box-mini-home-profile']"

with value "Writing a BDD presentation"

And I click element

"//*[@id='timeline']/div[1]/div/form/div[2]/div[2]/button"

Then I verify text present "Writing a BDD presentation"

BDD in Context

Tying into Agile

Common languagePO Dev QA

Common languagePO Dev QA

BDD as acceptance

criteria

BDD as requirements definition and Test First Then

Code methodology

BDD as functionality

definition and automated regression

Working together

Anyone can write a BDD!

Working together

We define our own language!

Working togetherOptimizing resource utilization

PO

DEV QAScenarios and steps

Adding BDD to your process

Work with POs to understand and learn to love BDDs

Work with developers to read and write BDDs

QA will be your biggest fan

Working with BDDMind the testing pyramid (Mike Cohn)

Write BDDs in the same sprint

Refactor, Refactor, Refactor

BDD -> CI -> Regression report

UI

Service

Unit

Sample Regression Report

FAQHow to create coverage for an existing system?

Which BDD framework language to pick?

Why not use QTP or some version of clicks recorder/capture?

Do POs really need to speak “fluent” Gherkin?

Behavior-Driven DevelopmentBDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agilemethodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

Questions

More slides this way

RedFlagDeals Case StudyQ1 2012 – Large code base, no unit test, manual QA only

Q2 2012 – BDD framework introduced, QA start to dabble in it

Q3 2012 – First new component to have 100% BDD code coverage

Q1 2013 – BDD roll out across the team, PO training

Q2 2013 – Over 60% coverage on legacy components

Today – 587 scenarios, 10,353 steps (executed)Full nightly regressionCommit triggered BDD executionAgreed on failure review and correction processAutomation being part of the Definition of Done

More Gherkin featuresTags

@DailyRegression

Feature: rss

@STORY-5859 @Staging @Local

Scenario: check vital signs

Given I go to …

TablesAnd call the url “www.site.com” with parameters

| Parameter Name | Parameter Value |

| search_string | agile |

| page_number | 5 |

Refactoring stepsWhen I click on the Submit button

When I click on the Clear button

When I click on the “Publish” button

When I hover over the “Help” button

When I “hover over” the “Help” button

When I “hover over” the “Avatar” image

When I “hover over” the control “image” called “Avatar”

Using MocksBDD driven automation behaves like a user, easy to start clicking on “real” or staging apps/sites/etc.

Somewhere, someone had just put up a prod database snapshot

Closing pitchCommon language!

Code based documentation that is readable by all.

Better resource utilization in the team.

A natural extension to an Agile process.