Foreword

Behaviour-driven development has come a long way since I first started talking about it in 2003. At that time, I was simply trying to find better ways to explain the revelatory practice of TDD, usually to nervous, suspicious, or at the very least skeptical programmers. Why would you write tests ahead of any code? That didn’t make sense. And why were we writing tests anyway—don’t we have testers for that?

Very few things represent a genuine paradigm shift. Mostly the term is used by marketers to convince you to change your brand of toothpaste. According to the Free Online Dictionary, a paradigm^[1] is “A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them.” That’s right, a paradigm shift involves messing with someone’s sense of reality! No wonder they get uncomfortable.

TDD is one of those rare genuine cases, so it’s no surprise that many people are deeply skeptical when you start trying to introduce it. And it’s also not surprising that it took us several attempts at articulating it, in different ways, from different angles, and with different audiences, before we found something that worked. At first we started deep in the code, because that’s where the programmers were. Over time we were able to take the action closer to the business stakeholders and describe the multilayered approach that is modern BDD (and is also, ironically, classic TDD, which Kent Beck described from the very outset as working on multiple levels of abstraction).

Aslak Hellesøy has been part of the effort to describe that shift almost from the very beginning. As well as an early adopter of BDD—and a passionate advocate of TDD—he rewrote my sad efforts at building a scenario runner for RSpec into the tool we now call Cucumber. He has invested enormous time and effort into both the tool and its community, so it came as no surprise to learn he and Matt were writing a book on BDD in Cucumber. I love that they are targeting both developers and testers. If the tool isn’t bringing these two worlds closer together, then it’s the wrong tool.

I was delighted to learn that Aslak’s partner in crime would be Matt Wynne. Another passionate and experienced TDDer—and BDDer—Matt has been involved with Cucumber since day one. He is a fun and engaging speaker, is a great teacher, and has a wealth of knowledge and wit that comes across in his writing. In fact, I’m proposing that Matt Wynne be inaugurated as a unit of excellence, somewhere between a Win and an Epic Win. (Oh, cool, did you see that? That was better than a win; that was a Matt Wynne!)

I hope you enjoy this book as much as I did. My review notes from an earlier draft seem to contain the phrase “Oh, this is lovely” more times than I remembered. It feels like you are being led into a strange, yet somehow oddly familiar, world with two knowledgeable and accommodating guides. Oodles of examples, descriptions, and sidebars (Joe—who you’ll meet early on—quickly became my friend by asking the things I found myself asking) help you on your way, and the authors manage to keep the plot moving quickly enough to keep you engaged, which is always a challenge in a technical book.

I can’t say where BDD will be in another eight years, but with folks like Matt and Aslak sharing their innovation and clarity, now is a very exciting time to be involved in agile software development.

—Dan North, Lean technology specialist at DRW Trading and originator of BDD