Intro. to bdd
19
Intro. to BDD (Behavior Driven Development)
-
Upload
aaron-evans -
Category
Software
-
view
50 -
download
0
Transcript of Intro. to bdd
Intro. to BDD(Behavior Driven Development)
What is BDD?“ 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.”
-- DAN NORTH(CREATOR OF JBEHAVE TEST FRAMEWORK AND MANY BDD CONCEPTS)
What is BDD?“ 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.”
-- DAN NORTH(CREATOR OF JBEHAVE TEST FRAMEWORK AND MANY BDD CONCEPTS)
What BDD IS NOT?TEST FRAMEWORK
AUTOMATION
CUCUMBER
“GHERKIN” SYNTAX
The only way to Test
THE AGILE WAY to TEST
What BDD IS NOT?TEST FRAMEWORK
AUTOMATION
CUCUMBER
“GHERKIN” SYNTAX
The only way to Test
THE AGILE WAY to TEST
BEHAVIOR DRIVEN DEVELOPMENTBDD is about DEVELOPMENT
Not CODING
THE DEVELOPMENT PROCESS1. Customer wants a feature.
2. Define the feature.
3. Build the feature.
4. Test the Feature.
5. Deliver the feature.
6. PROFIT?
TAUTOLOGICAL DEFINITION OF BDDBDD is
An agile process
For Describing BEHAVIORS
That DRIVES the way
Software is DEVELOPED.
WT?It’s a way to write requirements
That can be understood by everyone (SEE DOMAIN DRIVEN DESIGN, by ERIC EVANS - no relation)
And Executed Directly.
IT’s EXECUTABLE DOCUMENTATION.
BDD & TDDBEHAVIOR DRIVEN DEVELOPMENT
Came from TEST DRIVEN DEVELOPMENT. (SEE EXTREME PROGRAMMING EXPLAINED by KENT BECK - also no relation)
IT REcognizes that Communicating with Non-Programmers is IMPORTANT
But that DOCUMENTATION can become outdated
And AUTOMATED TESTS are only readable by developers.
WHY DO BDD(multiple choice Quiz)
A. Management says so.
B. It makes testing easier.
C. To communicate BETTER.
D.ALL of the Above.
E. NONE OF THE ABOVE.
F. D & E
TWO (main) STYLES OF BDD CUCUMBER
GIVEN/WHEN/THEN
MORE DETAILEDMORE ORGANIZEDMORE RIGID
DOCS INDEPENDENT OF CODE
SPEC
DESCRIBE/IT SHOULD
MORE CONCISELESS STRUCTUREMORE FREEFORM
DOCS GENERATED BY CODE
CUCUMBER (1
of 3)Feature: [TITLE]
As a [ROLE]I want [FEATURE]SO THAT [BENEFIT]
Focus on the reason for developing a feature.
CUCUMBER (2
of 3)SCENARIO: [DESCRIPTION]
GIVEN [INITIAL CONTEXT]WHEN [ACTION]THEN [EXPECTED RESULT]
Describe each scenario with preconditions, steps, and expected results.
CUCUMBER (3
of 3)EXAMPLES:
Provide concrete examples.
USER
PASSWORD
COMMAND MESSAGE
aaron
SECRET
Open pod bay doors
ACCESS DENIED
dave
DAISY
Open pod bay doors
I’m SORRY DAVE, I’m afraid I can’t do that
SPEC (RSPEC, MOCHA)DESCRIBE([FEATURE])
It([BEHAVIOR])
...implementation
Documentation & implementation live together
WHEN TO USE CUCUMBER / GHERKINTypically used for user stories where product owner
is involved
and should write, (or at least approve of), the SPEC.
The spec is a mechanism for communication, not a way to dictate features.
WHEN TO USE MOCHA/RSPECTypically used for developer oriented tests.
DOcumentation is generated from code.
Good for reporting coverage, but not so much for collaboration.
The spec is used primarily for generating DOCUMENTATION.
THE ENDThanks.
https://linkedin.com/in/aaronevans
@fijiaaron
