BDD Thoughts
Behavior Driven Development to the rescue!
What is BDD?
Specifications that talk about business processes are worth much more over the long term.
Business users can participate in documenting business processes and provide much better feedback than they would on acceptance tests that pertain to software.
...comprehensive definition
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.
Hmm... can you repeat that?!
...comparing with TDD
- an evolution in thinking behind TDD
- it builds upon TDD by formalising the good habits of the best TDD practitioners:
- working outside-in
- examples for requirements
- ubiquitos language
BDD... a.k.a
- Clarity
- Vision
- Focus
- Confidence
But let's see BDD in action
In the beginning...
The product management team...
...has an idea
Next
The same idea...
BACKLOG
The team gathers around
Product Management
Business Analyst
Business Analysts???
Tech Leads
developers
...and testers
The team takes the the idea...
Various discussions emerge...
...and finally, a story appears
But the most important gain
...Shared understanding!
Where does UX/design come in play?
The UX and designer teams,
having all the info they need...
...are able to define the visuals.
Having the story clearly defined...
...with a set of predefined examples (which will be refined)
Tech leads are defining the architecture...
...and testers&developers are automating.
Given the ninja has a third level blackbelt
When hit on the head by a samurai with a katana
Then the ninja's brain should not be hurt
The results?
- Implementing changes more efficiently
- Higher product quality
- Less rework
- Better work aligment
- Living documentation
Could it be that easy?
Yes, when the software product has emerged from a shared collaboration
How about a practical example?
Let's see how this works with a BDD specific tool
Lettuce
To use a BDD tool right, one has to understand that the main goal is primarly about communication and secondarly about testing!
PBS User Story
As a User
I want to localize to a station
So that I am able to view the station's TV Schedule
Let's see how we test this
Developers and testers write the feature file.
Feature: TV Schedules is available after localization
Scenario: Once localized, user is able to see TV Schedule for that station
Given I am on the localization page
When I localize to a station
Then I am able to see TV schedule for that station
Main Advantage...Living Documentation
Long Term Value comes from Living Documentation!
- Living Documentation should be easy to understand
- Living Documentation should be consistent
- Living Documentation should be organized for easy access
Do we need BDD?
Let's decide this together. But keep in mind:
- No Living Documentation system in place
- No effective way of keeping tests cases up to date
- Shared understanding
- Why do we need this new feature/technical solution?
- Gap between views of stakeholders and technical people
- Automation code - as important as the application's code
- Ubiquitos Language
- We need to focus on what matters
Something witty to say!