MagenTys BDD Masterclass by Hamish Tedeschi

1. magentys_logo_2014.jpg
BDD Master Class

2. WHAT
 Behavioural Driven Development (BDD) is a design process in software
engineering where you focus on the behaviour of a feature/application. So
instead of writing tests you should think of specifying behaviour.
 BDD is Test Driven Development done with a specific mindset; testing the
intent of the system rather than testing a particular piece of code. The
difference is subtle but the effects are large.
 BDD means examples (or scenarios) are written *before* the implementation
of the software and happens iteratively, in collaboration with non-technical
stakeholders
 Automated acceptance tests are a by-product of BDD

3. 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

4. BDD (Behavioural Driven Development)
Requirements
Analysis
Design
Code
Test
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

5. 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

6. 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.

7. 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

8. 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

9. 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.