Upload
wakaleo-consulting
View
922
Download
1
Embed Size (px)
DESCRIPTION
Behaviour-Driven Development (BDD) is a game changer for the whole team! More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery. In this session, you will learn what BDD is about, its benefits, and how it affects development teams and processes. But you will also see BDD techniques applied to a real project using tools like JBehave, Cucumber, Selenium 2, Thucydides and more! - Learn how BDD helps teams focus on discovering and delivering the features that really matter! - Learn what it takes to write more relevant and more maintainable automated acceptance tests - Discover how a well-designed set of automated acceptance criteria can also be a powerful documentation and reporting tool. - See where BDD fits into a Continuous Delivery pipeline. - And learn how product owners use BDD and Thucydides to drive, coordinate and document releases. Learn how much more there is to BDD than just “Given..When..Then”!
Citation preview
@wakaleo#DV14 #bddinaction
BDD in ActionJohn Ferguson Smart Wakaleo Consulting
@wakaleo#DV14 #bddinaction
Miyamoto Musashi Japan
1584 – 1645
@wakaleo#DV14 #bddinaction
John Ferguson Smart
Consultant Trainer Mentor Author Speaker Coder
@wakaleo#DV14 #bddinaction
What is BDD A typical BDD workflow What tools should I use? Effec@ve BDD automa@on BDD Gotchas
@wakaleo#DV14 #bddinaction
A Test Automa@on Tool?
So what is this BDD thing?
@wakaleo#DV14 #bddinaction
A way to write acceptance criteria?
So what is this BDD thing?
@wakaleo#DV14 #bddinaction
A way to discover requirements?
So what is this BDD thing?
@wakaleo#DV14 #bddinaction
Using examples
a shared understanding
software that matters
So what is this BDD thing?
@wakaleo#DV14 #bddinaction
BDD
Hunting out value Automated Acceptance Criteria
API and code design
Collaboration
Building the software right
Building the right software
Living Documentation
@wakaleo#DV14 #bddinaction
The business owner tells the business
analyst what he wants
12 The business
analyst writes a requirements
document
3 The developer translates the requirements into software
4 The tester translates the requirements
into test cases 5 The technical writer translates
the software into functional and technical
documentation
BDD in a nutshell
A traditional development process
@wakaleo#DV14 #bddinaction
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
BDD in a nutshell
A BDD development process
@wakaleo#DV14 #bddinaction
The business owner and the business
analyst have a conversation about
what he needs.
1
2
3
4 The tester uses these scenarios as the basis for
her tests
5
The automated tests provide feedback on progress and help
document the application
The business analyst, the developer and the tester elaborate the
requirements together.
The scenarios guide the developer and act as
automated tests
They define requirements as
structured, English-language format
"scenarios"
•Specifica@ons are elaborated collabora@vely •Specifica@ons use a common language •Executable specifica@ons provide fast feedback
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
Why bother with BDD?
•Focus effort •Reduce waste and misaligned requirements
@wakaleo#DV14 #bddinaction
Why bother with BDD?
Deliver more valuable soMware
@wakaleo#DV14 #bddinaction
Why bother with BDD?
Make changes safely
@wakaleo#DV14 #bddinaction
Why bother with BDD?
Faster and more reliable releases
@wakaleo#DV14 #bddinaction
Why bother with BDD?
Reduced maintenance costs
@wakaleo#DV14 #bddinaction
Benefits of BDD
BDD in the real world -‐ an example
BDD
Demo
@wakaleo#DV14 #bddinaction
BDD requires high business engagement and collabora@on
Adoption challenges
Demo
@wakaleo#DV14 #bddinaction
BDD works best in an Agile or Itera@ve context
Adoption challenges
Demo
@wakaleo#DV14 #bddinaction
BDD does not work well in a silo
Adoption challenges
Demo
@wakaleo#DV14 #bddinaction
Adoption challenges
Skill and prac@ce required: •Wri@ng good scenarios takes prac@ce •Poorly wriQen tests can lead to higher test-‐maintenance costs •Need to treat test automa@on code like produc@on code
@wakaleo#DV14 #bddinaction
BDD Gotchas
12
3
4An@-‐paQern 1 The business analyst writes the scenarios and then gives them to the other team members.
@wakaleo#DV14 #bddinaction
12
3
4
BDD Gotchas
An@-‐paQern 2 The tester writes the scenarios at the end to implement an automated test suite.
@wakaleo#DV14 #bddinaction
1
2
3
45
BDD Gotchas
An@-‐paQern 3 The “Three Amigos” sessions don’t result in usable scenarios, so the developer invents them a=erwards.
@wakaleo#DV14 #bddinaction
1
2
3
45
BDD Gotchas
An@-‐paQern 4 The scenarios are too UI-‐centric or detail-‐focused, and neglect to express the core business value.
@wakaleo#DV14 #bddinaction
BDD for high-level requirements
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
Frequent Flyer Application Goal: Encourage travellers to fly with Flying High airlines more often by allowing them to cumulate Frequent Flyer points that they can spend on cheaper flights.
Goals
Earning points from flights
Capabili9es
Earning points from spending with partners
Viewing points earned
Spending points on bookings
FeaturesViewing current points balance
View points needed to achieve the next status level
Calculating points needed for a given destination
@wakaleo#DV14 #bddinaction
Calculating points needed for a given destination As a traveller I want to know how many points I need to go to a given destination So that I can plan my next trip with Flying High Airlines
Feature
Acceptance Criteria -Need 2 points per km -Members can calculate points needed on their account home page
Acceptance Criteria
Automated Acceptance Criteria
@wakaleo#DV14 #bddinaction
Automated Acceptance Criteria
Automated Acceptance
Tests
@wakaleo#DV14 #bddinaction
Automated Acceptance
Tests
Applica9on Code
Low level specifica9ons
@wakaleo#DV14 #bddinaction
A typical BDD workflow“But what are the deliverables?
Meaningful feedback on what requirements have (and have not) been delivered
@wakaleo#DV14 #bddinaction
An incremental approach“But what are the deliverables?
Descrip9on of each feature with an example of how it behaves
@wakaleo#DV14 #bddinaction
An incremental approach“But what are the deliverables?
…complete with illustra9ons
@wakaleo#DV14 #bddinaction
An incremental approach“But what are the deliverables?
How was each feature tested?
@wakaleo#DV14 #bddinaction
An incremental approach“But what are the deliverables?
Documenta9on about what you plan to deliver in each release
@wakaleo#DV14 #bddinaction
An incremental approach“But what are the deliverables?
Useful low-‐level technical documenta9on with liRle overhead
@wakaleo#DV14 #bddinaction
An incremental approach
“But what are the deliverables?
…and targeted automated regression tests
@wakaleo#DV14 #bddinaction
AngularJS SPA
Flights Web Service
Accounts Web Service
Flying High Application Architecture
Routes Web Service
@wakaleo#DV14 #bddinaction
Flying High Test Architecture
(aka Thucydides)
Demo
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
BDD for detailed coding
@wakaleo#DV14 #bddinaction
Business Goal
Business Goal
Business Goal
We can automate these examples in the form of “executable specifica@ons”
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
“building the software right”
@wakaleo#DV14 #bddinaction
Business Goal
Business Goal
Business Goal
We use low-‐level BDD or TDD tools to define the behavior of components, classes etc.
FeaturesFeaturesFeatures FeaturesFeaturesExamplesLow level
specificationsLow level specificationsLow level specifications
Executable specifications
spockRSpec
“building the software right”
Low level specifications
Low level specifications
Low level specifications
Low level specifications
Low level specifications
@wakaleo#DV14 #bddinaction
Acceptance criteria tell us what we need to build…
“building the software right”
@wakaleo#DV14 #bddinaction
What would we like the API to look like?
“building the software right”
@wakaleo#DV14 #bddinaction
Then write low-‐level specifica@ons for the code
“building the software right”
@wakaleo#DV14 #bddinaction
“building the software right”
These low level specifica@ons become technical documenta@on for your APIs
Demo
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
What tool should I use?
@wakaleo#DV14 #bddinaction
Collaboration before Automation
“Having the conversaDon is more important than
recording the conversaDon is more important than
automaDng the conversaDon” -‐ Liz Keogh
@wakaleo#DV14 #bddinaction
Know your audience
@wakaleo#DV14 #bddinaction
High-level BDD
Reporting for non-developers as well as developers
Communicate about features that business owners will understand and find meaningful
Higher automation and maintenance costs
…
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
+ Groovy
@wakaleo#DV14 #bddinaction
Living documentationRequirements reportingEncourages good test architectureGood WebDriver integrationWorks with other BDD tools
(Previously known as “Thucydides”)
@wakaleo#DV14 #bddinaction
+
@wakaleo#DV14 #bddinaction
+
@wakaleo#DV14 #bddinaction
A high-‐level BDD tool should Produce business-‐readable results Fit smoothly into your build pipeline Integrate with your development infrastructure Allow developers to collaborate with testers to implement and refactor the automa9on code
@wakaleo#DV14 #bddinaction
Tips for more effec@ve BDD Test Automa@on
@wakaleo#DV14 #bddinaction
Business Rules
Business Flow
Page/Component interac9ons
Page/Component details
Tip #1 - Use Layers
@wakaleo#DV14 #bddinaction
Tip #2 - Favour non-UI tests where possible
Tip #3 - Know when not to automate
This slide is left intentionally blank
@wakaleo#DV14 #bddinaction
Low-level BDD
Technical documentation for other developers
Implementation details that business owners may not be interested in
Faster to write and easier to maintain
spockRSpec
@wakaleo#DV14 #bddinaction
Low-level BDD
Good naming conven9ons are the first step towards BDD
@wakaleo#DV14 #bddinaction
Low-level BDD
spockRSpec
Readable executable specifica9ons in Groovy
Low-level BDD
spockRSpec
Great support for data-‐driven tests
Low-level BDD
spockRSpec
Powerful and light-‐weight stubbing and mocking
Low-level BDD
spockRSpec
Makes very readable specifica9ons
@wakaleo#DV14 #bddinaction
Low-level BDD
Lambda-Behave
Low-‐level BDD library for Java 8
Low-level BDD
Lambda-Behave
Data-‐driven specifica9ons
Low-level BDD
Lambda-Behave
Generated test data
@wakaleo#DV14 #bddinaction
A low-‐level BDD tool should Be highly readable Be developer-‐friendly Make it easy to think in terms of specifica9ons, not tests Encourage fast feedback cycles You may need several!
Demo
@wakaleo#DV14 #bddinaction
@wakaleo#DV14 #bddinaction
There’s more where this came from!
https://code.google.com/p/spock/
http://jbehave.org/
http://serenitybdd.com
@wakaleo#DV14 #bddinaction
There’s more where this came from!
And look for more material on parleys.com!
@wakaleo#DV14 #bddinaction
Thank You