inside behavior driven development

Inside Behavior Driven Development

Bal$more So+ware Prac$ces and Pa2erns April 19, 2016

Camille Bell

cbell@CamilleBellConsul$ng.com

Twi2er @agilecamille

ww.slideshare.net/Camille_Bell

Agenda •  What is BDD?

•  What is its value?

•  BDD and TDD Similari;es and Differences

•  Who par;cipates in BDD? What is the role of the customer/product owner?

•  Three parts of Any Test

•  Use of Business Language in BDD: what is a good BDD test?

•  What about teams that have tradi;onal manual testers?

•  What about teams that have developers but not testers?

•  What should be tested manually?

•  Demo

cbell@CamilleBellConsul$ng.com 2

BDD/ATDD == Agile Func;onal Tes;ng

•  Many names for the same thing:

–  Behavior Driven Development (BDD)

–  Acceptance Test Driven Development (ATDD)

–  Story Driven Development

–  Story Tes;ng

–  Specifica;on by Example

•  We'll call it Behavior Driven Development or BDD cbell@CamilleBellConsul$ng.com 3

BDD By any Other Name

•  There are some minor subtle differences between those terms, that don't maSer for most purposes (Developers tend to call it BDD and Testers ATDD)

•  Collaborate to define detailed acceptance criteria before developing applica;on code

•  Turn the criteria into executable acceptance tests (before developing applica;on code)

•  Watch test fail (no because no app code)

•  Then later pass, when app func;onality implemented


Value of BDD Over Tes;ng AUerwards

•  BeSer Documenta;on of Requirements – Automated tests are precise

•  Precise Audi;ng though automated traceability

•  Improved Dev Focus – Eliminates Goldpla;ng

•  Clear when you're done with a feature

•  Eliminates False Posi;ves that tes;ng aUer can cause

•  Ensures acceptance tes;ng gets done

•  Ensures acceptance doesn't slow down release

•  Can be integrated into Con;nuous Deployment Pipeline

•  Regressionable Spec -‐ Obvious if code and tests out of sync


Behavior Driven Development & Test Driven Development Similari;es •  Both specify behavior

•  Both use feedback loops

•  Both use automated tes;ng, not manual tes;ng

•  Both create tests with 3 main parts

•  Both create tests which can be run independently

•  Both lower defects

•  Both provide regressionable safety nets for change cbell@CamilleBellConsul$ng.com 6

Differences Between BDD and TDD (1)

•  BDD and TDD focus is different

–  BDD focuses on building the Right Thing (business value)

–  TDD focuses on building the Thing Right (technical quality)

•  BDD and TDD have different levels of granularity

–  BDD Scope is business func;onality

–  TDD Scope is soUware class and unit level


Differences Between BDD and TDD (2)

•  BDD and TDD par;cipants differ

–  BDD involves a greater variety of par;cipants

–  TDD is developer centric

•  BDD and TDD specifica;on languages differ

–  BDD test specifica;ons are in business language (e.g. Cucumber's Gherkin)

–  TDD test specifica;on languages is in programmer focused unit tes;ng language (e.g. JUnit, Rspec, CPPUnit, NUnit, etc.)


Test Driven Development Feedback Loop

Write a test for new low level func;onality

Run the test and watch it fail

(no code = test fails)

Write just enough code to make the

test pass


Run the test and watch it pass

Clean up complex or messy code

Run test again to make sure it s;ll passes

Check in Code & Tests


Simplified TDD Flow (oUen called Red-‐Green-‐Refactor

Write a failing unit test for new func;onality

Write just enough code to pass test

Refactored code must also pass tests, no new func;onality


TDD is Deep Inside Code: Tes;ng at Unit Level

BDD with TDD Flow (simplified)


REFACTOR

RED

GREEN

RED

GREEN

REFACTOR

TDD unit test level

BDD acceptance test level

JUnit, NUnit,

Rspec, etc.

Cucumber with

Gherkin

BDD with TDD Inner Feedback Loop (detailed)

Write a new step for BDD scenario


Clean up BDD

test code

Run BDD test again

to make sure it s;ll passes



Focus on One

Scenario

TDD unit test level

Run Scenario and watch Step fail

Run BDD test & watch step

pass

When step passes pull up to BDD

Drop down to TDD

Three Parts of Wri;ng any Test Cucumber/Gherkin

3 As Ruby

3 As Java

Formal Testers What it is

Given Assemble Arrange Precondi;on All the setup and dependencies for the test

When Ac;vate Act Ac;on/Event Something that happens that will make the outcome different than if it hadn’t happened

Then Assert Assert Expected Results or Postcondi;on

What is expected to happen and any side effects


Collabora;vely (Spec it/define tests) •  Some;mes called

the 3 Amigos (test, dev, business)

•  Conversa;on based

•  Focus on value

•  Specific examples

•  Concrete data

•  Outside in (business focus drives development)


BDD Test Automa;on Has 2 Sides

Business Facing

•  Simple English

•  In business terms •  Promotes collabora;on

•  Uses examples •  Uses concrete data •  Proves business needs met

•  Executable specifica;on •  Modifiable & reusable

Technology Facing

•  Exercises underlying SW

•  Connects to browsers, networks, databases, frameworks, etc,

•  Object Oriented •  Extensive test libraries •  Modifiable & reusable

•  Learnable programming language


Quali;es of a Good BDD Acceptance Test

•  In business language using terms common to that domain, so that your PO or customer can easily understands the test

•  Not vague, so that it is clear exactly what condi;ons make the test pass or fail

•  Just the right amount of detail, concrete data relevant to the scenario, but no extra

•  Not overly technical

•  Not scripty (no click here, etc.)

•  Let's see some examples


Too Vague


Scenario: Book search

When I search for a book

Then I expect to see the appropriate information

What type of search: by Author, ISBN, Title?

Successful or failed search?

What data are we using to search with?

What is the appropriate informa;on we should see: specific Author, ISBN or Title?

Too Technical


Scenario: Successful book search by author Given the following Authors: | id | name | | 1 | Jeff Morgan | | 2 | Gojko Adzic | | 3 | Matt Wynne | And the following Titles: | id | title | author_id | | 1 | Cucumber & Cheese | 1 | | 2 | The Cucumber Book | 3 | | 3 | Specification by Example | 2 | And I'm on "http://www.mybooks.example/" When I fill in "Morgan" in "//input[name()='query']" And I click "#seekButton" Then there should be 1 "div.book div.title" element And the page should contain "Cucumber & Cheese"

Crea;ng BDD Acceptance Scenarios •  User Stories, especially those created though story mapping,

are a good place to start talking about acceptance criteria

•  That can lead to thinking about categories of test scenarios (test ;tles)

•  Given, When, Then comes next

•  Make sure there is concrete test data

•  Let's see how it works


In order to conduct banking when the bank is closed

As a bank customer

I want to use an ATM

Why?

Who?

What?

Why does your user want this?

Your idea probably needs to be broken down into smaller stories.

Who is this user? How is he/she different from other users.

What exactly does your user want?

Start with an idea for an App (like ATM banking)

These ideas are called User Stories.


Sample ATM Stories (Features)

Cash Withdrawal :

In order to get money when the bank is closed

As a bank customer

I want to withdraw cash at the ATM

Check Deposit :

In order to deposit my checks when the bank is closed

As a bank customer

I want to deposit checks at the ATM

Transfer to Savings:

In order to earn interest even when the bank is closed

As a bank customer

I want to transfer money from checking to savings at the ATM

Transfer to Checking:

In order to not overdraw my account when the bank is closed

As a bank customer

I want to transfer money from savings to checking at the ATM


Choose a Story (Feature) (to become an automated test)


As a bank customer


Feature: Cash Withdrawal


As a bank customer



Acceptance Criteria will become our specs (test scenarios) when they have details

Feature: Cash Withdrawal


As a bank customer


•  Successful Withdrawal •  Less than balance •  Equal to balance

•  Withdrawal Failed Due to Insufficient Funds

•  Withdrawal Failed Because Cash Dispenser Doesn’t Dispense One Dollar Bills

•  Withdrawal Failed Because Account Closed

First Cut Acceptance Criteria for several tests cbell@CamilleBellConsul$ng.com 26

•  Successful Withdrawal

Given my account has been credited with $100

When I withdraw $20

Then $20 should be dispensed

And the balance of my account should be $80

Choose a Scenario and Define the Steps in Testable Detail


•  Successful Withdrawal (less than balance)

Given my account has starting balance of $100

When I withdraw $20


And the ending balance of my account should be $80

Given, When, Then format – Business language with unambiguous detail

Detailed Acceptance Criteria

These detailed acceptance criteria are acceptance tests that are executable specs


With Minor Changes it can become an Automated Test (Cucumber's Gherkin)

•  Successful Withdrawal


When I withdraw $20



Scenario: Successful Withdrawal


When I withdraw $20




The Structure of Cucumber Features

Feature: [ feature title ] As a user [ role ] I want [ feature ] So that [ business value ]

Scenario: [ scenario title ] Given [ a pre-condition ] And [another pre-condition ] When [ event ] Then [ post-condition outcome ] And [ another post-condition outcome ]

Plain Text Key

Words

From User Story

Ref: Cucumber code examples from “The Cucumber Book” by MaS Wynne and Aslak Hellesøy


Example Cucumber Feature


Step Defini;ons


Cucumber Command Line


Plus the Evolving Code Under Test (Ruby example, code could be in any language)


•  Successful Withdrawal (equal to balance)


When I withdraw $100



Add More Scenarios



When I withdraw $120



And I should see a message containing "insufficient funds"

•  Failed Withdrawal (insufficient funds)

Features

Scenarios

Automa;on Libraries (e.g. rspec, page-‐object, wa;r-‐webdriver, etc.)

Support Code (e.g. env.rb, hooks.rb, Gemfile, your custom page objects)

Business Facing

Technology Facing


Step Defini;ons

Cucumber/PageObject Technology Stack

Gherkin (English-‐like business language)

Built-‐in Ruby Libraries for

Tes;ng

Ruby (oUen modified templates)

Steps wriSen in Ruby

Steps

•  Testers learn the business side of BDD quickly, but oUen are challenged by technology side

•  Testers add important perspec;ve in three amigos sessions

•  Make sure that the PO/customer approves of the scenario wording and any changes to it (needs to readable to PO)

•  Testers responsible for wri;ng all acceptance tests

•  Testers can learn technology side of BDD. Business needs to provide training, coaching and pa;ence (see my talk "Growing Manual Testers into Automators")

•  Pair Testers and Developers to speed learning technology side


Teams with Tradi;onal Manual Testers

Teams of Only Developers

•  Devs learn the technology side of BDD quickly, but oUen are challenged by business side

•  Developers tend to think "happy path", so have another dev or BA take the role of "devil's advocate" in three amigos session too flesh out error scenarios

•  Make sure that the PO/customer approves of the scenario wording and any changes to it (needs to readable to PO)

•  Developers responsible for wri;ng all acceptance tests

•  BDD tests do NOT take the place of TDD unit tests, TDD unit tes;ng


Mob Programming •  Whole team works together

•  On the same thing

•  At the same ;me

•  In the same space

•  Using the same computer

•  Driver rotates •  Everyone par;cipates •  Great for training & prac;ce •  Great for collabora;on •  Everyone up to speed faster •  Some teams mob always, others frequently

•  Features delivered faster – single piece flow /wo handoffs cbell@CamilleBellConsul$ng.com 39

Some Tes;ng Shouldn't Be Automated •  Look and Feel – Does the corporate logo look right?

•  Usability – Is the app easy to use?

•  Page Layout of PDF documents – Easier for a human to inspect

•  Readability – Humans must verify readability

•  Transla;on – Does the Spanish page say the same thing the English page does?

•  Data Input Integrity (garbage in/garbage out)

•  Legalese – Some;mes a lawyer must verify the page text (unless lawyer is part of the Amigos session)


BDD & TDD Stoplight Demo

Resources

and

References

Resources – BDD Overview and Value

•  How tests become Executable Specifica;ons – Explains without coding, also good overview for anyone

–  Specifica$on by Example: How Successful Teams Deliver the Right So+ware by Gojko Adzic


Available from Amazon or Manning hSps://www.manning.com/

Managers, Requirements Analysts, Product Owners and others who want to understand the concepts, human interac$ons and value of BDD / ATDD

Resources – Cucumber Books Ignore references to headless Rails tes$ng unless using Rails

•  Cucumber with Ruby – General

–  The Cucumber Book: Behavior-‐Driven Development for Testers and Developers by MaS Wynne & Aslak Hellesoy

•  Advanced Cucumber Topics

–  Cucumber Recipes: Automate Anything with BDD Tools and Techniques by Ian Dees, MaS Wynne & Aslak Hellesøy


Available from Amazon or the Pragma;c Bookstore hSps://pragprog.com/

Resources – Free Cucumber Info Cucumber Wikis

•  Both wikis focus on headless Cucumber (not in browser with PageObject), but provide useful info on Cucumber and Gherkin

•  Older Wiki – easy to explore format, contains some info not in new wiki hSps://github.com/cucumber/cucumber/wiki

•  Newer Wiki – contains some nice blogs and plug for semi commercial product and support hSps://cucumber.io/


Resources – Free Ruby Info

Ruby 101 – the basics: (Learn Ruby 2.x not Ruby 1.9)

•  On-‐line tutorials – my favorite is Ruby Monk hSps://rubymonk.com

Learn to navigate the documenta$on:

•  Ruby's built-‐in classes and methods are very rich.

•  Testers should learn to check if the needed func;onality already exists

•  Ruby docs are found at hSp://ruby-‐doc.org/


ALL

SOME

Resources – Cheezy's Book Cucumber with PageObject – Best approach to web tes$ng (IHMO)

•  Covers Cucumber, Gherkin, PageObject, Wa;r, Selenium, etc. used in web demo

•  Step by step tutorial with exercises

•  SoUcopy only, work in progress, updated periodically

–  Cucumber and Cheese: A Testers Workshop by Jeff Morgan


Available only from Lean Pub hSps://leanpub.com/cucumber_and_cheese

Resources – Free PageObject Info Cheezy's (Jeff Morgan's) Blog

•  Other Cheezy blog posts are also worthwhile hSp://www.cheezyworld.com/2011/07/29/introducing-‐page-‐object-‐gem/

Official documenta$on

•  PageObject is a gem.

•  Like most gems, it and its documenta;on can be found on GitHub (scroll down) hSps://github.com/cheezy/page-‐object


Resources – Free Detailed Demo Cheezy's Demo Tes$ng Puppies Site

•  Uses RubyMine IDE, but other editors or IDEs work fine

•  Covers a later example from Cucumber and Cheese book resource

•  1 hour 10 minute YouTube video hSps://www.youtube.com/watch?v=zpt15XIjpas


Resources – Ruby Books If Ruby Monk is too challenging, try Learn to Program

•  For those who haven't programmed before (most manual testers)

–  Learn to Program -‐ Second Edi$on by Chris Pine

•  For those who know object-‐oriented programming in some other language (includes more Ruby than most testers will need)

–  Programming Ruby 1.9 & 2.0 by Dave Thomas

•  For a problem-‐based approach to wri;ng small pieces of Ruby that do useful things

–  Everyday Scrip$ng with Ruby by Brian Marick


Available from Amazon or the Pragma;c Bookstore hSps://pragprog.com/

Camille Bell

Agile Technical & Process Coaching Retrospec;ves

Agile Boot Camps Agile Training Updated Slides

or just to chat about things agile cbell@CamilleBellConsul$ng.com

Twi2er @agilecamille

inside behavior driven development

Software