Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BDD

No description
by

Tom Philip

on 25 November 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BDD

... about writing software that matters - Dan North
... 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
... an outside-in development approach that focuses on the value, the user story
BDD?
... a collection of existing principle/practices brought together from
XP - TDD and CI
Acceptance Test Driven Planning
Lean Principles
DDD
..about implementing an application by desribing it behaviours from the perspective of it stakeholders - Dan North
...it's many things, it's still evolving
It's...
Brighton Dance Division
...in its grandest sense is about communication and viewing your software as a system with behaviour. - Dave Astels
Feature: Authentication
As a customer
I want to identify myself to the Website
So I can get my purchases
TDD done right
Lets rule the galaxy
Less of this
more of this
Like...

Become No.1 seller of digital jazz
What's in a good story?
Software delivery is about writing software to achieve business outcomes. - Dan North
Title (one line describing the feature)
As a <role>
I want to <feature>
So that <benefit>
Write stories on cards
Create them from outcomes from feature discusions
Get stakeholders, bas, qas and developer involved
This give
The story in detailed, expressed as a list of scenarios
I specify behaviour
Change your language you use in your tests
Automate, Automate
... and remember
Sapir-whorf
The language we use effects how we think.
Code by Example
Stories
Business Outcomes
Acceptance Criteria
Who's it for, who to talk to about it
Why do they want it?
Documentation (for everyone)
A starting point for knowing we're done
Describe the feature as a story
Executable documentation - the only truth
Automated regression tests
Given <context>
When <action>
Then <observation>
become acceptance tests
How do we create these?
Achieve the business outcome with an application that has x,y,z features
How do we create these?
Create them in cleartext from discussion between Qas and developers
Use tools like Cucumber and SpecFlow to turn them into tests
Run them continously
Describe scenarios in what (feature) not how (implementation)
Beware magic strings in acceptance specs
Further define the story
Code the scenario
Guided by our acceptance specs
They're are coding guide, showing us where to start and when to end (done!)
I don't write tests
Scenario: Login with shop account
Given I have an account
When I sign in
Then I should get logged in
And I should see my purchased products
Scenario: Login with Facebook
Given I have a Facebook account
And it's linked to my shop account
When I sign in with Facebook
And authenticate my Facebook account
Then I should see my purchased products
Scenario: Wrong password on login
Given I have a shop account
When I sign in with the wrong password
Then I should not get logged in
And I should be warned that I have entered my password incorrectly
Isn't this just TDD?

Detailed executable documentation
... 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
.. it's all about communication
It all starts with a vision
Lets sell digital music
Vision
How do we communicate this vision?
Like...
Stop losing customers
an example
Start from the outside with what you know
Work your way inwards mocking collaborators as you go
Stop when your acceptance spec is green, repeat.
Create your own DSL (No magic strings)
How do we code this?
Tom Philip
@tommysqueak
Mind shift
Test Fixture = Specification/Scenario
Test Setup = Context
Test = observation (Then)
Assert = Should
Design by example
Given <context>
When <action>
Then <observation>
It's all about the Language
Closing Thoughts
It's all about the language
Truthful Documentation
Scenario: Getting tracks for an album
Given I have an album with 2 tracks
When I get the tracks
Then they should be ordered by track number
[Show Code]
Scenario: Failing Authentication
Given the login details are invalid
When I sign in
Then I should be redirected to forgotten password page
[Show Code]
http://blog.conkersoftware.co.uk
Postboxed
Great Boxee
Meet legal requirements
Unit Tests
High quality working software, thats readable, modular and easy to change
Scenario
specs
unit specs
Not started scenario
Communicate
Acceptance Specs
Bake quality in at the beginning
Talk around and create stories incl scencarios
Reduce waste and confusion
Validate often
Add Value
Quickly, incremently, feedback
[Show Code]
[Draw]
Full transcript