1. Behavior Driven Development Vermont Code Camp September 11, 2010 By Tom Cooley

3. Developer for 20+ years

4. C# for 7+ years

5. Primary focus includes:

6. Object-oriented architecture

7. Design patterns and principles

8. Database development/DBA for 14+ years

9. Co-leader of VT SQL Server user group

10. Member of International Association of Software Architects

12. BDD Overview

13. The Ubiquitous Language of BDD

14. The BDD Story

15. Specifications

16. Tools and toys

18. Evolution of TDD Learning and Adoption The developer starts writing unit tests around their code using a test framework like JUnit or NUnit. As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work. 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. 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. 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. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behavior rather than testing. 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

19. Story Time Once upon a time…

21. BDD Story Semantics As a <role> I want <some feature> So that <business value> As a speaker I want to be able to select a preferred time of day to present So that I can accommodate my travel plans to attend Code Camp

22. User Acceptance Tests Scenarios Given <pre-condition> And<another pre-condition> When <behavior is performed> Then <outcome> And <another outcome>

23. Scenario 1: Presentation is scheduled according to preferred time of day Given a speaker with an early morning preference And the schedule has an open time slot that matches the preference When the coordinator schedules the session using the speakers preference Then the session is successfully scheduled And 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 preference And a matching time slot is available When the coordinator assigns the session to an afternoon time slot Then the session is not scheduled And the number of open time slots should not change And a warning occurs indicating the conflict Scenario 3: All time slots matching speaker’s preference are taken Given a speaker with a morning preference And a matching time slot is available When the coordinator assigns the session to begin in the morning Then the session is scheduled And the number of open time slots in the schedule is one fewer

24. 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

25. Tools & Toys StoryQ – 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.

26. Resources Email 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.aspx http://blog.jpboodhoo.com/BDDAutoHotKeyScriptUpdateTake2.aspx