Behavior Driven Development

V E R M O N T

CODE CAMPSeptember 11, 2010

By Tom Cooley

Tom Cooley• Principal Software Architect at MyWebGrocer• Developer for 20+ years• C# for 7+ years

• Primary focus includes:• Object-oriented architecture• Design patterns and principles

• Database development/DBA for 14+ years• Co-leader of VT SQL Server user group• Member of International Association of

Software Architects• Presenter at VT .NET and VT SQL Server user

groups

Session Overview• Why is testing so hard?• BDD Overview• The Ubiquitous Language of BDD• The BDD Story• Specifications

• Tools and toys• and of course…demo code

Unit Testing

The good, the bad, the ugly

Evolution of TDD Learning and Adoption1. The developer starts writing unit tests around their code using a test

framework like JUnit or NUnit. 2. As the body of tests increases the developer begins to enjoy a

strongly increased sense of confidence in their work. 3. At some point the developer has the insight (or is shown) that

writing the tests before writing the code, helps them to focus on writing only the code that they need.

4. The developer also notices that when they return to some code that they haven't seen for a while, the tests serve to document how the code works.

5. A point of revelation occurs when the developer realizes that writing tests in this way helps them to “discover” the API to their code. TDD has now become a design process.

6. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behavior rather than testing.

7. Behavior is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD.

Source: http://behaviour-driven.org/Introduction

Story Time

Once upon a time…

BDD Story SemanticsAs a <role>I want <some feature>So that <business value>

As a speakerI want to be able to select a preferred

time of day to presentSo that I can accommodate my travel

plans to attend Code Camp

User Acceptance TestsScenariosGiven <pre-condition>And<another pre-condition>When <behavior is performed>Then <outcome>And <another outcome>

Scenario 1: Presentation is scheduled according to preferred time of dayGiven a speaker with an early morning preferenceAnd the schedule has an open time slot that matches the preferenceWhen the coordinator schedules the session using the speakers preferenceThen the session is successfully scheduledAnd the number of open time slots in the schedule is one fewer

Scenario 2: Presentation is scheduled into time slot that does not match the speaker’s preference

Given a speaker with an early morning preferenceAnd a matching time slot is availableWhen the coordinator assigns the session to an afternoon time slotThen the session is not scheduledAnd the number of open time slots should not changeAnd a warning occurs indicating the conflict

Scenario 3: All time slots matching speaker’s preference are takenGiven a speaker with a morning preferenceAnd a matching time slot is availableWhen the coordinator assigns the session to begin in the morningThen the session is scheduledAnd the number of open time slots in the schedule is one fewer

Context-Specification Style[Context]When scheduling a session using a

speaker’s preference[Specification]should assign to earliest time slot that

matches speaker preference[Specification]Should assign earliest available time slot

when no others match speakers preference

Tools & ToysStoryQ – a library that uses Domain

Specific Language (DSL) of Behavior Driven Development

NBehave – similar library. I use for extension methods to assert outcomes

AutoHotKey - Automate almost anything by sending keystrokes and mouse clicks. You can write a macro by hand or use the macro recorder.

ResourcesEmail me at: tom@cooley.name

http://dannorth.net/introducing-bdd

http://behaviour-driven.org/

http://storyq.codeplex.com/

http://nbehave.codeplex.com/

http://www.autohotkey.com/

http://blog.jpboodhoo.com/BDDAutoHotKeyScriptUpdateTake1.aspxhttp://blog.jpboodhoo.com/BDDAutoHotKeyScriptUpdateTake2.aspx