This last week, I ramped-off the first project I've been on using Behavior-Driven Development. It was a Rails project and so we used Cucumber. As I looked out across the web, I found a few beacons around the actual practice of BDD. There's some good stuff out there, but I couldn't find anyone that is going past the theory and sharing the tacit knowledge. This is my first attempt at starting to fill that gap.
First, I want to contextualize BDD and share some resources to get started. Then, I give some concrete observations from our project and lay out a set of principles and practices that we followed or discovered.
Advancing The State of The Craft
Dan North's Behavior-Driven Development (BDD) is proving to be another key stepping stone in our journey, as an industry, toward what Uncle Bob has called "professional craftsmanship".
One of the fundamental practices in BDD is "outside-in programming". Programming efforts are driven by attempting to meet a specification of the software's behavior as quickly as feasible. "Specification" sounds pretty rigorous, doesn't it? ...and a good specification is.
The most useful specifications come with examples that concretely express what "done" looks like. This is really important, because if you can get this concrete, you can start to have meaningful conversations between the folks driving the business and the kids writing the software. Paired with visuals (story board of wireframes ... aka "User Interaction Designs"), you can really start to have design discussions with actionable, trackable results.
In this way, examples facilitate quality communication -- the means by which intention, vision, and detail are shared. Good stuff! But wait, there's more...
What if you could express your specifications as examples in a concrete enough way that you could automate the execution of them? Suddenly, the "definition of done" is more firm (if the automated example doesn't run successfully, you're not done). And if the examples are abstract enough, we can expect to execute them not just when the software is developed, but also as part of a regression suite. Each time you run it, reinforcing your confidence that "everything is still working." Wow! That's a lot of value being realized. But can it be done?
We're really asking...
Is it possible to express acceptance criteria as examples that they:
That's a tall order... but that's exactly what BDD is driving towards. If we have any hope of getting there, we'd have to see:- are written in language understood by both business and software people?
- are meaningful enough to act as a catalyst for converging on the "right" software solution to the business problem at hand?
- are concrete enough to be executed by a computer?
- are abstract enough that one can expect them to function long after that part of the software is complete?
- exactly how these kinds of examples are written;
- precisely how they are made executable with a minimal effort;
- and how these practices fit within the software development process.
Thankfully a huge chunk of this ground has been expertly covered. David Chelimsky covers the very foundations of this discussion in The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends (with significant contributions from Dave Astels (author, RSpec contributor and BDD evangelist), Zach Dennis, Aslak Hellesøy (original author of Cucumber), Bryan Helmkamp, and Dan North (credited with the term BDD and write RSpec's “Story runner," the predecesor to Cucumber). As Robert Martin eloquently explains in the forward (posted right on the PragProg page for the book), the title of the book is misleading; it would be more aptly titled "BDD in Action".
Before he published his book, Chelimsky developed a presentation:
Integration Testing in Ruby with RSpec’s Story Automation Framework" which contains enough detail that it can be read on its own.
Integration Testing in Ruby with RSpec’s Story Automation Framework" which contains enough detail that it can be read on its own.
What Chelimsky's book covers is how Behavior-Driven Design can be realized in the Ruby world (and specifically when developing web applications with Ruby on Rails). As the title suggests, his book walks you through a mini website development project employing the BDD approach to identify and using Cucumber to write the very kinds of executable Examples we're talking about here.
While not the first of its kind, Cucumber has in the past year become the tool of choice for Rails shops that are adopting BDD
(Alex Handy wrote a fine article about Cucumber and included its brief history, titled "Peeling Cucumber").
(Alex Handy wrote a fine article about Cucumber and included its brief history, titled "Peeling Cucumber").
What's needed, then, are reports from the field: empirical data and observations that fill-in the important details on how a project team realizes the benefits of BDD.
Having completed my first such effort, I'm no expert. But I have done it and definitely have some insight to share. In the next weeks, I will be unspooling a series that makes an attempt to being to fill this gap:
- sharing observations about how Feature authoring unfolds, in practice;
- enumerating principles and practices around writing Features and Scenarios;
- discuss similar guidelines for smartly implementing your Cucumber Steps;
- suggesting a set of common templates and features that you should include in your Example automation suite.
Next...
Before we charge into the kitchen and start mixing it up, let's take a quick survey of the Ingredients...
References:
Professional Craftsmen
- http://en.wikipedia.org/wiki/Robert_Cecil_Martin
- http://www.infoq.com/presentations/craftmanship-ethics
- http://en.wikipedia.org/wiki/Dave_Astels
- http://www.linkedin.com/pub/zach-dennis/1/aa1/38
Behavior-Driven Development
- http://behaviour-driven.org/
- http://en.wikipedia.org/wiki/Behavior_Driven_Development
- http://www.pragprog.com/titles/achbd/the-rspec-book
- http://www.martinfowler.com/bliki/BusinessReadableDSL.html
No comments:
Post a Comment