Nathaniel Neitzke Lighthouse1, LLC [email protected].

23
BEHAVIOR DRIVEN DEVELOPMENT Nathaniel Neitzke Lighthouse1, LLC [email protected]

Transcript of Nathaniel Neitzke Lighthouse1, LLC [email protected].

Page 1: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

BEHAVIOR DRIVEN DEVELOPMENT

Nathaniel Neitzke

Lighthouse1, LLC

[email protected]

Page 2: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Test driven development

Where did it come from?

What is it?

Page 3: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Why automated tests?

To verify correctness?

Page 4: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Confidence

Ability to change

Page 5: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Isolation

Debugging is hard, time consuming

Page 6: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Design

BDUF Goldplating

Page 7: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Documentation

What does this code do?

Page 8: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Testability

Send quality code to QA

Page 9: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

So what’s wrong with tdd?

Focus on tests so it must be testing right?

Sapir-Whorf

Page 10: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

The problem with “unit”

What is a unit? Unit test -> class

Page 11: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Programmers think…

I’m not going to write all those tests It’s really simple code, it doesn’t need to

be tested Testing is a waste of time I’ve done this all a million times (loops,

data retrieval, functionality, etc…)

Page 12: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Manager’s think…

We test after the code is done That’s what we have a testing person for We can’t spend that time now

Page 13: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Behavior driven development

TDD done very well Not about tests Think differently

Dan North/Aslak Hellesøy 2004

Page 14: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Specifications

Executable specifications around the behavior of your system

Page 15: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

User stories

Conversation between customer and developer

Drive our executable specifications Role, feature, benefit

As a [role] I want [feature] so that [benefit]

Page 16: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Scenarios

Detail acceptance criteria for a particular user story

Context – Action – ObservationGiven [Context] When [Action] Then

[Observation]

Page 17: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

FormatTitle (one line describing the story)

Narrative:As a [role]I want [feature]So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1:Given [context] And [some more context]…When [event]Then [outcome] And [another outcome]….

Scenario 2: ….

Page 18: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

rspec & cucumber

Frameworks/Tools

Page 19: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

DEMO

Page 20: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

.NET Frameworks

NBehave, .NETSpec Machine.Specifications

Page 21: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Other Tools

TextMate/e Autotest Heckle Rake RCov

Page 22: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Resources Dan North

http://dannorth.net/introducing-bdd http://dannorth.net/whats-in-a-story

RSpec http://rspec.info/

Cucumber http://cukes.info/

IronRuby http://www.ironruby.net/

Beyond Test Driven Development Video http://video.google.com/videoplay?docid=8135690990081075324

The RSpec Book: BDD with RSpec, Cucumber, etc.. http://www.pragprog.com/titles/achbd/the-rspec-book

Page 23: Nathaniel Neitzke Lighthouse1, LLC nightski@gmail.com.

Questions?