In mid-August, the week after the big Agile conference, I led a “Behavior-Driven Development for Everyone” webinar for the Toronto Agile Community.
Problems are better solved when you’re better involved. That’s how you make your living, and that’s what BDD is all about. We’ll work together to solve a problem in a way we can all understand and trust, expressing what we want in plain English and automating our tests with a tool called Cucumber. Don’t worry, you won’t be put on the spot at the keyboard — I’ll handle all the coding!
What we did
There were several dozen people watching online as I programmed out loud with Cucumber in Perl, taking questions along the way. Of course, it wasn’t nearly as collaborative as a group of two or five could be. We tried to mitigate the unidirectionality by stopping regularly for question breaks, and to elucidate the differences between my unilateral onscreen actions and BDD as it is meaningfully and collaboratively practiced.
The video:
What I learned
In the webinar, side-by-side-by-side, I live-coded the human-readable Gherkin spec, the programmer-readable step definitions that bring the spec to life, and the code being developed to meet the spec.
In doing this, my intention was to illustrate how these three pieces are connected (or might fail to be) and how they must evolve together — in other words, to give concrete impressions of the cost of maintaining Cucumber tests and of the value they might provide in return.
We didn’t get to retrospect together, but I suspect a couple things worked somewhat well for the group:
- Choosing a notoriously difficult-to-read language of implementation, to drive home the point that it’s not necessary to understand the code to understand the state of the product
- Demonstrating what a developer’s work looks like when Cucumber is involved
I think I could have delivered more on my intention to illustrate Cucumber’s cost and value as a BDD-supporting tool if I’d spent less time typing. Next time I present this material, if we can’t do it collaboratively (as I did for AgileIndy last year), I’ll use a technique I’ve used before and simply forgot about:
- Develop the demo code in advance, committing at each interesting change
- With the audience, move through the changes at leisure using Magnus Stahre’s git-crawl.
Read more
In addition to the references in the slides, here’s a story of my own about seeking greater effectiveness through BDD, from my series about the human value of TDD.
Learn more
What would BDD look like in your context? Need help getting started? Get in touch! If you’re in the New York metro area or willing to try a remote consultant, I’d love to work with you. Otherwise, I’m happy to refer you to an expert hands-on instructor in your area.