An introduction to BDD using cucumber java as an example. Making comparisons with TDD

1. BEHAVIOUR DRIVEN
DEVELOPMENT
An Introduction by Qaiser Mazhar

2. AGENDA
 Introduction
 BDD in Java
 DEMO
 Further Reading
 Q&A

3. WHY DO PROJECTS FAIL?
 Delivering Late
 Over Budget
 “Wrong Product”
 Unstable
 Hard to maintain

4. BUILDING SOFTWARE THAT MATTERS
 On time (even if in parts)
 Easy deployment and maintenance
 Real Business Value
 Robust
 Easy to understand and communicate

5. ISN’T TDD ENOUGH?
 TDD is fantastic for the technical design of your product
 TDD’s concern is with doing things “the right way”
 BDD is concerned with doing “the right thing”
 Different levels of granularity and goals
 BDD is an evolutionary step from TDD

6. WHAT IS BDD?
 BDD is a “2nd-gen, outside-in, multiple-stakeholder, high-
automation, agile methodology”
 Provides a ubiquitous language for multiple stakeholders both
business and technical.
 Creates a suite of executable stories
 Non-technical up to date documentation
 Verifies specification
 Puts barriers around “how much to test”

7. WHAT IS BDD NOT?
 A replacement for unit tests
 Replacement for QA testing process
 Replacement for contact with the business – feature scenarios
are still too low level

8. KEY CONCEPTS
 In agile:
 Story
 As a role
 I want some feature
 So that some value was generated – important!
 A story’s acceptance criteria defines it’s behaviour
 In BDD:
 Feature
 Scenario (Example of a feature in action)
 Given an initial context
 When an event occurs
 Then ensure there were some outcomes

9. CONCRETE EXAMPLE
 Story: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

10. CONCRETE EXAMPLE
 Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

11. CONCRETE EXAMPLE
 Scenario 2: Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned

12. BDD IN JAVA USING CUCUMBER
 Cucumber is one way to use BDD in Java.
 Simple set up
 Jenkins report plug in
 Cucumber supports Ruby, Java, .NET, Flex and Web apps written
in any language
 Good IntelliJ support
 Can be used in conjunction with selenium
 Cucumber supports over 40 spoken languages
 Java Alternatives: JBehave, Easyb, Jdave & more…

13. BDD IN JAVA USING CUCUMBER
 Feature files are written in Gherkin – a business readable domain
specific language
 Feature files are linked to a “glue” file that defines the java test
steps (the steps are run by jUnit) referred to as step definitions
 The glue class calls the actual code of your system and tests it
*.feature
StepDefini
tions.java
*.java
*.feature
*.feature
*.java
*.java
Glue File System CodeFeature Files

14. GHERKIN IN DETAIL
 "feature“
 "background“
 "scenario“
 "scenario_outline“
 "examples“
 "given“
 "when“
 "then“
 "and“
 "but”

15. GHERKIN IN DETAIL
 “language": "Scouse",
 "feature": "Feature",
 "background": "Dis is what went down",
 "scenario": "The thing of it is",
 "scenario_outline": "Wharrimean is",
 "examples": "Examples",
 "given": "Givun|Youse know when youse got",
 "when": "Wun|Youse know like when",
 "then": "Dun|Den youse gotta",
 "and": "An",
 "but": "Buh"

16. GHERKIN IN DETAIL
 “language": "Australian",
 "feature": "Pretty much",
 "background": "First off",
 "scenario": "Awww, look mate",
 "scenario_outline": "Reckon it's like",
 "examples": "You'll wanna",
 "given": "Y'know",
 "when": "It's just unbelievable",
 "then": "But at the end of the day I reckon",
 "and": "Too right",
 "but": "Yeah nah"

17. ADVANCED FEATURES
 @Before
 @After
 Tagged hooks
 background
 Scenario outline and example tables

18. BEST PRACTICES
 Features and Scenarios should be high level and focused
 Avoid steps that do too much, use “And” or “But” instead
 Reuse step definitions and keep refactoring them
 Use tags to organise scenarios e.g. by execution time or when
they should run etc
 Use a library to make dealing with time in your step definitions
look natural
 Refactor, refactor, refactor…

19. DEMO

20. FURTHER READING
 Dan North’s seminal article on BDD:
http://dannorth.net/introducing-bdd/
 Cucumber home page: http://cukes.info/
 Have a play!

21. Q&A