magentys_logo_2014.jpg

BDD Master Class

WHAT

Behavioural Driven Development (BDD) is a design process in softwareengineering where you focus on the behaviour of a feature/application. Soinstead of writing tests you should think of specifying behaviour.

BDD is Test Driven Development done with a specific mindset; testing theintent of the system rather than testing a particular piece of code. Thedifference is subtle but the effects are large.

BDD means examples (or scenarios) are written *before* the implementationof the software and happens iteratively, in collaboration with non-technicalstakeholders

Automated acceptance tests are a by-product of BDD

Traditional

Requirements

Analysis

Design

Code

Test

If Testing shows the

requirement has not

been met then the time

has been lost

Feedback loop takes

time as code is

deployed and devs

wait for test results

Only when code is

written is it identified

that it can’t meet the

design

BDD (Behavioural Driven Development)

Requirements

AnalysisDesign

CodeTest

Feedback loop is

continuous and

happens throughout

each cycle

Deliver incremental

changes into

production quicker for

faster results

Team collaboration

up front removes

Chinese whispers

Collaborate

WHY

Lets use the “5 Whys” technique to help understand why we use BDD

Q1. Why would we use BDD?

A1. To get a better quality product

Q2. Why?

A2. Because we (often) get it wrong

Q3. Why?

A3. Because there are misunderstandings, ambiguities or errors in what has been specified

and/or what we eventually get in the form of the product

Q4. Why?

A4. Because the traditional methods for specifying behaviour are not always effective in

capturing

Q5. Why?

A5. Because they fail to use concrete examples and a ubiquitous language

THE PROBLEMS WITH BDD

It is NOT a silver bullet, but is often perceived as one

In reality, it is about design and has nothing to do with test automation, but is often

thought of as a test only activity, which means it will FAIL. It is a TEAM activity and

requires a high performing, collaborative and technical one, to be a success.

It does not negate the need for testing. In fact, it means exploratory testing is

essential, as we should aim to capture 80% of scenarios before we develop. We

are agile and accept that things change and aim to document system behaviour not

tests.

There can be a disconnect between the features and scenarios captured and what

they become upon implementation. This is a technical problem which can be

solved with good business process and there will be technology that can solve this

Only one of these problems (the last one) is a REAL problem with BDD. The

rest are team based problems which can be easily solved.

COMMON BDD MISTAKES

The most common mistake is tying the scenarios (or acceptance criteria) too closely to the implementation. This is the difference between using Declarative and Imperative language.

An Imperative example:

Given I am on the log in page

When I enter user name “Hamish” and password “pa55w0rd”

And I click the log in button

Then I will be logged in

Why is this example bad?

1. It has made a number of assumptions (more likely) or prescriptions (even worse) about what the system should appear like, when really the intent or behaviour is to just validly log in

It assumes or prescribes a log in page

It assumes or prescribes a user name and a password field is required

It assumes or prescribes a button to log in is required

This dictates to technical teams how the feature should be implemented and will probably mean that when it is built the feature, step definition and page object code will all need to be refactored

COMMON BDD MISTAKES

A Declarative example:

Given I have logged in to the demo application with valid credentials

Then I should see the demo application welcome message

Why is this example better?

1. It specifies the intent or behaviour without tying it to the implementation

This means that technical teams can implement this however they choose, as long as they ‘log in’ and

see a welcome message -> SO TEAMS ARE FREE TO USE THEIR CREATIVITY -> TEAMS ARE

HAPPIER

It means if the implementation changes less refactoring is required. The feature files and step definitions

are unlikely to change, however, the page object may change. For example, if we go from a user name

and password required, to windows authentication with no user name and password, then this scenario

is still valid, however, the previous one is not

1. It is smaller, more succinct and uses more eloquent language

COMMON BDD MISTAKES

The second most common problem (I see) is writing ambiguous scenarios or ones which use

inconsistent grammar

A real life example:

When I edit additional details like Authorised

And I can update the corporate client record

Then I can find the corporate client record when I search

Why is this example bad?

1. The "When" steps use "I can", which imply that the user can do something rather than does do

something. A "When" should be an action not an intention, which is either granular, or at a higher

level.

2. The "Then” steps use "I am" or "I can". This often leads to questioning of the result or

ambiguities. Using "should" means a contractual obligation and tends to lead to less

questioning. It marks the sentence, or expected result, as a requirement, which of course, in

agile, can of course be negotiated, but it is a starting point for discussion.