7. First approach
TDD Test Drive Development
0 Is not a tool!!!! It’s a design methodology
0 Focused in unit testing
0 Life cycle
0 Red
0 Green
0 Refactor
0 Something is missing:
0 THINK!
0 Think Red Green Refactor
8. TDD is fine but…
• Is programmer focused
• Only take care about the source code
• Helps to write code right but not right code
• Not support communication
0 Inside team (including QA, BA, Data analyst…)
0 With stakeholders
• Is bottom – up process
9. BDD History
BDD was developed by Dan North as a
response to the issues encountered
teaching TDD
0 Where to start in the process
0 What to test and what not to test
0 How much to test in one go
0 What to call the tests
0 How to understand why a test fails
0 Give you reliability your tests?
10. BDD History
• The first proposes was that the unit testing
names be whole sentences starting with the
word SHOULD and written in order of
business value.
0Every class should do something
• ClientDetailsValidatorTest
0ShouldFailForMissingSurname
0ShouldFailForMissingAge
12. Definition
• BDD is a second-generation, outside-in, pull-
based, multiple-stakeholder, multiple-scale,
high-automation, agile methodology. It
describes a cycle of interactions with well-
defined outputs, resulting in the delivery of
working, tested software that matters.
• Using examples to create a shared
understanding and surface uncertainly to
deliver software that matters.
14. Story
• What’s an story?
It has to be a description of a requirement and its
business benefit, and a set of criteria by which we all
agree that it is “done” (Dann North)
• Written in business language
15. Story
• Structure:
0 Title (one line describing the story)
0 Narrative:
0 As a [role]
0 I want [feature]
0 So that [benefit]
16. Story
Example:
0 As a user
0 I want to publish a tweet
0 So that share information with my followers
17. Story
Another template:
0 Title (one line describing the story)
0 Narrative
0 In order to [benefit]
0 As a [role]
0 I want to [feature]
18. Story
Example:
0 In order to share information with my followers
0 As a user
0 I want to publish a tweet
19. Scenario
• It’s the acceptance criteria
• It’s a description of each specific case
of the narrative
• Can be used to help discover the scope
of the story or the feature
• The scenario should be described in
terms of Givens, Events and Outcomes
20. Scenario
Structure:
0 Title (one line describing the scenario)
0 Narrative
0 Given [context]
0 And [some more context]...
0 When [event]
0 Then [outcome]
0 And [another outcome]...
21. Scenario
Example:
Given a twitter account activated
When I send a tweet with 139 characters
Then the tweet is published
And all my followers can read the tweet
22. How to build scenarios?
Only 4 keywords have the empowerment
to build scenarios
0 but something is missing…
What is the most powerful tool to build
the scenarios?
25. User Story & Scenario Example
Title: 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.
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
26. User Story & Scenario Example
Scenario 2: Account has insufficient funds
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
27. User Story & Scenario Example
Scenario 3: Card has been disabled
Given the card is disabled
When the customer requests cash
Then the ATM should retain the card
And the ATM should say the card has been retained
30. BDD Life cycle
• Let’s choose a problem Given a
number, what is its factorial?
• User Story:
0 Feature: Compute factorial
0 In order to learn BDD
0 As beginners
0 We'll implement factorial
31. BDD Life cycle
• Writte the first scenario:
• Scenario: Factorial of 0
0 Given I have the number 0
0 When I compute its factorial
0 Then I see the number 1
36. BDD Life cycle
Add the another scenarios:
0 Scenario: Factorial of 1
0 Given I have the number 1
0 When I compute its factorial
0 Then I see the number 1
0 Scenario: Factorial of 2
0 Given I have the number 2
0 When I compute its factorial
0 Then I see the number 2
37. BDD Life cycle
0We don’t need change the steps in python
because we haven’t changed the definition
40. BDD Life cycle
• We can add more scenarios and
improve the software quality:
0 What happen when we introduce a character?
0 What happen when we introduce a float?
0 What happen when we not introduce nothing?
0 …
42. BDD Life cycle
First:
0 Analyze the feature
•Google API about geography codification:
0 We want offer a product to improve the geography
knowledge
0 As a user we need a product that when a city is
introduced the application returns the country.
43. BDD Life cycle
0User story:
0 As a user
0 I want know the country code of one city
0 In order to improve my geography knowledge
44. BDD Life cycle
• We start thinking about the possible
scenarios to build the acceptance
criteria:
0 What happen if the city not exists?
0 What happen if the city parameter is null?
0 What happen if the city is mispelled
0 Should the request be authenticated?
45. BDD life cycle
Scenario Outline: Retrieve the geolocation with city
name given
Given a <city> name
When I request the geoencoding of the city
Then I obtain the <city> name with the <country_code>
Examples:
| city | country_code |
| Barcelona | ES |
| Paris | FR |
| San+Francisco | US |
46. BDD life cycle
• Code the scenario!
• Every line in the scenario is a function or
method in the code.
0 Given: Preconditions settings
0 When: API request
0 Then: Assertions
48. BDD life cycle
• Build the source code
• Remember build only the source code
required to pass the scenario
• If something is not required, delete it
50. BDD life cycle
Refactor:
0 Give feedback to the stakeholders and the whole team
0 Refactor the source code to improve it!
0 Refactor the scenarios
0 Add new scenarios
53. Communication
Improve communication
0 BDD is about conversations
0 Ubiquitous language (shared between stakeholders and
whole team)
0 Collaboration between stakeholders, Bussiness
Analysts, QA and programmers
Speak the same language = building
toguether
54. Documentation
• Formal documentation is not required
• Scenarios can be used as a software
documentation
• Every time the software changes… the
scenarios should be changed also (red,
green, refactor)
Live Documentation!!!!
55. Other benefits
• Only code the required functionality
(YAGNI)
• Quick feedback
If the tests are included in the CI
• Involve stakeholders in the
implementation process
• Develop code right and right code
• Give confidence in your code refactors
56. Resources
0 http://dannorth.net
0 http://lizkeogh.com
0 http://
www.slideshare.net/ajaydanait1/behavior-driven-development-bdd-16779998
0 http://behaviour-driven.org/
0 http://cukes.info/
0 http://lettuce.it/
0 http://fitnesse.org/
0 http://www.concordion.org/
0 http://jbehave.org/
0 User Stories Applied: For Agile Software Development, Mike Cohn
0 Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin
and Janet Gregory
0 Specification by Example, Gojko Adzic
