Post on 20-Jun-2015
description
transcript
!
Behavior-driven Development
@vgoldin
Intro…
Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.
BDD yet another *DD???
Bridge the gap between business outcomes (i.e. capabilities) and code
establish common understanding of scope, between business folks, the analyst, the developer and the tester
make acceptance criteria executable
From the Vision to the CodeVisio
n
Goal
Cap
ability
Feat
ure
Story
Scen
ario
Code
* every level focuses on certain aspect
What makes a good Story?
Should follow the INVEST principle:
Independent
Negotiable
Valuable
Estimateable
Small
Testable
User Story and BDDUser Story = Business Outcomes
Acceptance Criteria = Scenario*
Test Case = Executable Scenario (i.e. behaviour)
* — Is not replacement for conversion. Is the result of conversation.
* — Scenario is a example of specification by example
The structure of the story
Title (one line describing the story) Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Scenario 2: ...
TDD => BDD
Test => Behaviour
Testing => Verifying Behaviour
Obvious starting p0int
JBehave
…
…
…
…
Demo
Hidden benefits…Unambiguous acceptance criteria
Clean User Stories
Impact delivery vs. feature delivery
Team collaboration improves domain knowledge
Awesome code coverage
No waste in code
Don’t let your process hide your ignorance!
Referenceshttp://jbehave.org/
http://dannorth.net/introducing-bdd/
http://dannorth.net/whats-in-a-story/
http://gojko.net/2013/09/30/writing-as-a-user-does-not-make-it-a-user-story/
http://impactmapping.org/delivering.php
http://specificationbyexample.com/key_ideas.html