Your SlideShare is downloading. ×
Why do you say BDD if it is Cucumber?
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Why do you say BDD if it is Cucumber?


Published on

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

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

Published in: Software, Technology

1 Comment
  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 | | @EnriqueSanchezB