why do you say bdd if it is cucumber?

Post on 18-Nov-2014

416 Views

Category:

Software

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

How to define good features, scenarios and steps without care about the tool you are using.

TRANSCRIPT

Why do you say BDD if it is Cucumber?

Or How I Learned to Stop Worrying and Love the Behavior

Enrique SánchezTechnical Team Lead @ Medianet Software

CUCUMBER =/= BDD

BDD is a software development process Cucumber is a tool

“”

All of these tools are great… but, in the end, tools are tools. While RSpec and Cucumber are optimized for BDD, using them doesn’t automatically mean you’re doing BDD.

BDD is a MINDSET not a TOOL

What the f**k is BDD then?

Eng

ine

eri

ng Product

Miscommunicationbetween stakeholders, product, devs…

“”

56% of all bugs can be traced to errors made during the requirement stage.

Tom deMarco

“ ”68% failed projects

Standish Group Report 2009

How to solve this gap?

Gherkin

Define a narrativeWhy? Feature name, Actor, behavior, benefit What? Scenarios and steps

Feature

In  order  to  Value proposition

As  a  Role/actor

I  want  to feature description

Scenario

Given  setup

When  user  interaction/change

Then  outcome (assert)

How to create a narrative?

Forget the implementation

Who cares about code? Product and Marketing don’t think in code

Define a featureStart with expectations Instead of setting state or user actions Keep Scenarios simple Split complicated workflows

DeclarativeBe concise Don’t be Shakespeare Not unnecessary steps Remember YAGNI

AbstractionDescribe a feature, not edge cases Think in requirements Only BDD the happy path There’re controller/model/view tests

Assert only once

Only assert on Then steps No more user actions after a Then

Now you can choose your tool

Design, code, reuseUse the right tool for the right job What are you testing: web, mobile, service? Think in the language Ruby, Python, Java…

Narratives

Examples Describe

ImplementEmergent Design

BDD Club Rules

The first rule is you have to talk The second stories should speak with the customers terminology The third rule stories are not specs The fourth rule keep the story goals as real values for the customer The fifth rule stories should not be exhaustive The sixth rule stories should not be too low level or high level The seventh rule stories should slice through multiple layers The eighth, if it’s your first day you have to talk and ask

Questions?Thank you!

Enrique Sánchez | hola@enrique-sanchez.me | @EnriqueSanchezB

top related