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
Made with Slides.com