-
sbohlen 4.71
Description:
You’re Agile. You write User Stories. Now what? The next step is often to turn those User Stories into executable tests that can help you validate the proper behavior of your complex software systems. Behavior-Driven Development (BDD) is the engine that can help to drive this process on your project. The logical evolution of the often too fine-grained process of Test-Driven Development, BDD not only represents a somewhat different technical practice but, more importantly, it also suggests an entirely different way of thinking about your system and the way in which you test it.
In this session we will begin with a series of simple User Stories and demonstrate how the BDD process supports our codifying these User Stories into a series of “executable specifications” that can be used to validate the proper functionality of our complex software system. We will work at first without any of the complex overhead of so-called ‘BDD Frameworks’ to demonstrate the important concepts of BDD and then move on to investigate how and why one might look to use various ‘BDD Frameworks’ to offload some of the repetitive work often involved in the BDD process. Attendees should expect to leave with a good understanding of both the conceptual process that is Behavior-Driven Development as well as some of the technical practices that can help support its successful adoption.
The ideal attendee will have several years’ experience in developing complex software solutions. Some understanding of the role of User Stories in the Agile software development process is helpful but not required. Prior exposure to the concepts behind automated unit testing is assumed, but deep unit testing experience is not required.

Steve, I very much like the visuals in your slides. They worked nicely with your talking points. I do have one suggestion. The transition from user story to unit testing on slide 16 felt bumpy. It wasn't clear at that point why you would jump to unit tests. I think it is because you were showing the engineer's perpsective on user story and you actually want to highlight the potential for disconnection. You might add a slide before 16 to show that--maybe show an engineer looking at a user story card and "seeing" unit test code on the card instead of the actual story narrative.
Hope this helps, Dave