BDD
Implementation Patterns
workshop
Polyglot Unconference 2014
Vancouver, Canada
Martin Suchanek
mrtn@nrd.io
@mrtn_su
Anitec
3 years
PayByPhone
3 years
PlentyOfFish
8 months
workspace
join the group chat:
https://vancouverbdd.slack.com
#polyglotworkshop
say hi, and let us know:
what hats you wear (dev, qa, product, etc)
what bdd tools you use
Motivations
Understand the model and abstractions
don't get caught up in implementation details
Pick up any tool and run with it
01
BDD Overview
1.01
What are the goals of BDD?
1.02
What are the means by which we do BDD?
1.03
What does the end state of BDD look like?
De-emphasize the technology
While automation is a key part of BDD
(having specs always executing is a fundamental requirement for them staying relevant),
and technical/implementation constraints guide the way we write our specs,
ultimately it's all about the end state, for which the tech should merely be an ambient enabler.
1.04
What functional roles stand to benefit from BDD, and how?
Optimize your technical implementation
for the functional roles that are involved
Depending on your organization, zero or more functional roles will be invested in the BDD process.
Optimize for those that are.
For example, if only DEV and QA hats are doing BDD, the implementation will be a bit different than if non technical PO hats were involved.
If you know you want to involve other roles in the future, take this into account and realize that you will have short term overhead as a result.
It's all about the Ubiquitous Language
Means:
| Communication | Language |
| Collaboration | Shared Language, Context |
| Automation | Language with certain fixed constraints, conventions |
Ends:
| canonical living documentation | writing |
| a single source of truth | ubiquitous |
| a shared artifact | written |
| automatically validatable | written instructions for computer |
| trusted | ubiquitous |
| essential | ubiquitous |
BDD is a layer of abstraction, indirection
02
The Anatomy of a BDD toolset
2.01
If you had to tell a computer about your software under test,
how would you describe it in terms of its pieces?
Use the PageObject pattern
The pageobject patterns encapsulates the description of your software.
2.02
If you had to tell a computer about how your software under test is supposed to behave,
how would you encode this?
Use Stories, UAT, GWT
2.03
If you had to tell a computer how to interact with your software
(e.g. using a browser to visit a website),
how would this API look?
2.04
If you took the Description, Specification, and Driver,
how would you instruct a computer to execute the specifications?
2.05
If a computer executes the above specifications, what do you expect it to give you?
03
The Tooling Landscape
3.01
What BDD tool do you use?
each tool
has a different (prescribed, opinionated) approach to combining the
Description,
Specification,
Driver,
Execution,
and Documentation
aspects
In general,
There are Two classes of BDD tooling
Those that face the business: plain text (gherkin)
vs
those that face the programmer: programmatic DSLs
Note: both can output reports; the differentiator is who can author specs
04
Back to the DSL
4.01
How could we represent Description in gherkin?
4.02
How could we represent Specification in gherkin?
4.03
How could we represent Driver in gherkin?
4.04
How could we represent Execution in gherkin?
4.05
What is the different between an imperative specification, versus a declarative one?
Imperative vs Declarative is a spectrum
Have both at your disposal.
Let each spec determine where you fall on the spectrum.
Have readability and communication be the determinants of this.
Community
Meetup
http://www.meetup.com/VancouverBDD/
Twitter
@VancouverBDD
Slack
https://vancouverbdd.slack.com
BDD Implementation Patterns workshop Polyglot Unconference 2014 Vancouver, Canada
BDD Implementation Patterns - Polyglot Vancouver 2014
By Martin Suchanek
BDD Implementation Patterns - Polyglot Vancouver 2014
- 639
