2. BDD
• Behavior-driven development (BDD) is an
increasingly popular variation on test-driven
development, which helps developers think
more in terms of “executable specifications”
than in terms of conventional tests
3. Why use BDD?
• Only build feature that add real value
• Less wasted effort
• Better communication
• Higher quality, better tested product
• Traceability
4. BDD
• BDD describes TDD done well
- removes word ’test’
- replace it with
behaviour, examples, scenarios etc.
• Good habits;
1. Working outside-in
2. Using examples to clarify requirements
(scenarios)
3. Using a common (ubiquitous) language
5. BDD – Value Driven
• A good goal should add value to business
- increase revenue
- reduce cost
- avoid future cost
- protect revenue
”Increase revenue by allowing
customers to…”
”Prevent current customers
switching to competing product
by …”
6. BDD – What Does the Customer Need?
• Good teams push back!
- users tend to express requirements as implementations
- we need to find the business need!
We need caching
Why?
So that the page
loads fast
So that the
customer will buy
stuff on our site and
doesn’t leave page
Why?
Ok, so to increase the chance a customer
will buy [stuff] it need to be ’fast’. Caching
might be one way to achive this, but
compressing images might be more
effective. Or another way might be
loaders, or ..
7. BDD – Better understanding
• Working outside-in
- if you need to explain to a computer how to check the
requirement, you’ll need to be damn sure understand it
yourself
• Business black-box testing is often done manually!
- BDD enables automated acceptance testing
• Mininum effort /code to fulfull requirement
8. BDD – Common Language
• Common Language
- communication often the biggest overhead
- even bigger if you allow different dialects of terminology
- takes time but gains significant advantage
11. BDD - Stories
Story: Basic Purchase flow - User purchases a Grundpaket (id 21)
Narrative:
In order to attract new CDK customers
As a leading channel reseller
I want to provide an easy way to buy our products through our website
Goal come first
Stakeholder is
secondary
The feature must be
required to achieve this
goal
12. BDD - Scenarios
• The ’perfect’ bridge between the business-
facing and technology-facing sides of a team
Scenario: User selects a channel package for purchase (id 21.2)
Given address search is done with address street Hantverkaregatan streetNo 28 and city
Helsingborg on page url http://...
When user select totalpaketet by clicking on choose button
Then the user starts a purchase flow where the first step is called Grundpaket och box is
shown
Common language which is
reflected all way down in the
code
13. BDD - Java
• CDK use Jbehave
- lots of documentation
- uses Gherkin language
15. BDD – CDK Implementation
• No stories/scenarion from start
- Emma wrote a lot of BDD stories
- used by CDK as ’lightweight’ acceptance test
• Selenium
- browser automation
• Spring as embedded runner
- gives us DI
• Page template patterns (see code)
16. BDD – CDK Implementation
• Pros
- another way of thinking of test
- sentence instead of test (even for our Junit
tests)
- we could make our major refactoring with
confidence
• Cons
- selenium (engines)
- issus/bugs with JBehave (fetching
parameters, mapping to POJO)
- we should not come up with the goal
18. Lambdaj
• An internal DSL to manipulate collections
without loops
• Large part of business logic is always the
same; iteration over collections of business
objects to do a set of tasks
• Loops (especially nested and mixed with
conditions) are hard to read that to be written
• for loop is inherently serial