This document discusses the difference between Behavior-Driven Development (BDD) and Cucumber, a tool used for BDD. While Cucumber can be used for BDD, it does not guarantee that BDD is being properly practiced. BDD is a mindset and process that focuses on defining features and scenarios from the perspective of stakeholders to reduce miscommunication between teams. Gherkin language and Cucumber tool can be used to define narratives in a simple format understood by all teams. The document provides guidelines for writing effective scenarios using this approach to achieve emergent design through examples and collaboration between teams.

1. Why do you say BDD if it is
Cucumber?
Or How I Learned to Stop Worrying and Love the Behavior

2. Enrique Sánchez
Technical Team Lead @ Medianet Software

3. CUCUMBER =/= BDD

4. BDD is a software development process
Cucumber is a tool

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

6. BDD is a MINDSET not a TOOL

7. What the f**k is BDD then?

8. Engineering
Product

9. Miscommunicationbetween stakeholders, product, devs…

10. “
”
56% of all bugs can be traced to errors made during the
requirement stage.
Tom deMarco

11. “ ”
68% failed projects
Standish Group Report 2009

12. How to solve this gap?

13. Gherkin

14. Define a narrative
Why?
Feature name, Actor, behavior, benefit
What?
Scenarios and steps

15. Feature
In
order
to
Value proposition
As
a
Role/actor
I
want
to feature description

16. Scenario
Given
setup
When
user
interaction/change
Then
outcome (assert)

17. How to create a narrative?

18. Forget the implementation
Who cares about code?
Product and Marketing don’t think in code

19. Define a feature
Start with expectations
Instead of setting state or user actions
Keep Scenarios simple
Split complicated workflows

20. Declarative
Be concise
Don’t be Shakespeare
Not unnecessary steps
Remember YAGNI

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

22. Assert only once
Only assert on Then steps
No more user actions after a Then

23. Now you can choose your tool

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

25. Narratives
Examples Describe
ImplementEmergent Design

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

27. Questions?
Thank you!

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