Anti Patterns of BDD - Shrini kulkarni

1. Anti Patterns of BDD
Shrini Kulkarni
April 2016

2. Roll back in time …. How did BDD begin ?
• TDD had started breaking off
• Key question : Where to start the process?
TDD – starts with “Test”
• Developers hated word “Test”
• Confusion of TDD as Dev Practice
• What to call a test ?
• Problem space (domain) became complex –
Technology language became inadequate to
represent what system do
• Popularity of DSL
• Bring Business Analysts/Domain SME’s into
software party !!!

3. BDD - In Action
Move from loads/pages of documentation to
smaller and crisp documentation
Use of Formal Language with specific keywords
(DSL)
Story and Scenario (or Acceptance Criteria)
Common and Shared artifact between dev, BA,
Test and stakeholders
As <Some Role>
I want <Some Feature>
So that < Some desired outcome>
Scenario <Outline>
Given <Some pre condition>
When <Some action by user or system>
Then <Expected behavior>

4. What problems BDD was (is) supposed to
solve?
• Get rid of confusion about where to start and phrase
“test”
• When test fails – it should be obvious where it failed
and why
• In a complex problem domain - Technical Language
seems inadequate
• Lack of common language amongst tech, business
and stakeholders
Note : Automation was not in original scheme of BDD
• Replace “Test” by “Behavior”
• Test method names should be “sentences”
• Specify requirements in Gherkin – keywords
Communicationamongst Stakeholders, Programmers, Testers and BA’s

5. Fast Forward to 2016 ...
&

6. Anti Patterns Observed …
• Its all about Tool/Framework
• Cucumber and Automation as Powerful Distraction than help
• Dominating Imperative (implementation centric) style
• Using BDD as ceremony to claim to be Agile
• Converting existing test cases to BDD scenarios
• Using BDD as new Avatar of “Scriptless Automation”
• Using BDD as solution for development or testing problems

7. What can we do ?
• BDD is about having conversations with real humans – Liz Keogh
• BDD scenario is an idea not a contract nor a promise
• Having conversations > capturing conversations > automating scenarios
• Encourage declarative style BDD stories (interface bound than
implementation)
• Avoid temptation to convert a given test case to one BDD scenario
• You do not have to use Cucumber or do automation to do BDD
You don’t get a special license to create highly coupled tests just because you are doing BDD – Dan North

8. BDD – Tester’s View point
• Participate in BDD conversations enthusiastically wearing explorer’s hat
• Do not be very serious about BDD scenarios – they are no more than bunch
of test ideas – while testing go beyond them
• When writing automation code – follow good coding/design principles – do
not hide under BDD layer of automation
• Take test design seriously
• Invest time in sharpening your modelling, questioning and investigation
skills – regardless
• Collaborate all times with other functions and people in the team
• Be a useful team member in Agile or otherwise-project
Final D in BDD stands for development. BDD is neither about testing nor about Automation - Dan North

9. Thank you
shrinik@gmail.com
http://shrinik.blogspot.com
@shrinik