BDD in Action: Behavior-Driven Development for the whole software lifecycle (2015)

Preface

When I finally sat down to write about the origins of this book, I realized that my involvement with Behavior-Driven Development goes back much further than I thought.

My first foray into the world of executable specifications was in 2001, though at the time, I didn’t know it by that name. In fact, at the time, I didn’t know it had a name. I was working on a project to write a pricing algorithm for an insurance company. Along with a hefty 200-page Word document, the client kindly provided us with an Excel spreadsheet containing 6,000 or so rows of sample data that he used to check pricing changes. It was an afterthought: the idea was that we might find the spreadsheet handy to check our pricing application manually. I found it more convenient to set up a test harness to load the Excel data, run it against our pricing algorithm, and check the outcomes. While I was at it, I got the test harness to write an updated version of the spreadsheet—but with extra columns for the calculated values, highlighted in green if they matched, and red if they didn’t.

At first nothing passed, and the spreadsheet was solid red. Then, I implemented the application bit by bit, following the large formal specifications document provided by our client, and, gradually, more and more of the spreadsheet went green. We even found a number of errors in the specifications along the way! The resulting code had a near-zero defect rate, and a delighted customer, and my first experiment with what would now be called Acceptance Test Driven Development and Living Documentation was a hit.

I didn’t actually hear the term “Behavior-Driven Development” for another six years or so. While I was working on the Java Power Tools book in 2007, my good friend Andy Glover added an offhand question in one of his emails: “Quick question—what are your thoughts on BDD?” “Bee what?” I thought to myself, before running off to read Dan North’s seminal article on the topic.^[1] And it immediately clicked. Dan had crystalized what I thought the next steps in testing practices should be.

¹ http://dannorth.net/introducing-bdd/, first published in March 2006

I soon became involved in the BDD community, contributing to Andy’s BDD tool for Groovy, easyb,^[2] and experimenting with other BDD tools and approaches, and BDD soon became an invaluable part of my tool kit when helping teams out with their agile adoption.

² http://easyb.org/

Fast-forward four years: on a sunny summer day in January 2011, I met Andrew Walker in a cafe opposite Hyde Park in Sydney to discuss helping to get his teams started with TDD, BDD, and test automation. Andrew became a good friend, and we had many fascinating discussions, particularly around the ideas of Agile requirements management, executable specifications, and living documentation.

The Thucydides^[3] project was born of these conversations and from an idea—would it be possible to produce meaningful living documentation by observing the execution of automated acceptance tests as they run?

³ http://thucydides.info

Andrew was also the one to point out that I should write a book on the topic. In early 2013, I finally got in touch with the folks at Manning with the idea of a book on BDD. They were interested, and so a new book project was launched!

This book is a labor of love about a topic I hold close to my heart. I regularly see confusion and misunderstanding in the community about what BDD is (and isn’t). One of the goals of this book is to give the broader software development community a better understanding of what BDD is, where it can be used, and how it can help. My hope is that you will find as many benefits in practicing BDD as I have.

About this Book

The goal of this book is to help get teams up and running with effective BDD practices. It aims to give you a complete picture of how BDD practices apply at all levels of the software development process, including discovering and defining high-level requirements, implementing the application features, and writing executable specifications in the form of automated acceptance and unit tests.

Audience

This book has a broad audience. It’s aimed both at teams who are completely new to BDD, and at teams who are already trying to roll out BDD or related practices, like Acceptance-Test-Driven Development or Specification by Example. It’s for teams who struggle with misaligned and changing requirements, time wasted due to defects and rework, and product quality. It’s for practitioners whose job is to help these teams, and it’s for everyone who shares a passion for discovering better ways to build and deliver software.

Different people will get different things out of this book:

· Business analysts and testers will learn more effective ways of discovering requirements in collaboration with users, and of communicating these requirements to development teams.

· Developers will learn how to write higher-quality, more maintainable code with fewer bugs, how to focus on writing code that delivers real value, and how to build automated test suites that provide documentation and feedback for the whole team.

· Project managers and business stakeholders will learn how to help teams build better, more valuable software for the business.

How the book is organized

The book is divided into four parts, each addressing different aspects of BDD:

· Part 1 presents the motivations, origins, and general philosophy of BDD, and concludes with a quick practical introduction to what BDD looks like in the real world.

· Part 2 discusses how BDD practices can help teams analyze requirements more effectively in order to discover and describe what features will deliver real value to the organization. This section lays the conceptual foundation for the rest of the book and presents a number of important requirements-analysis techniques.

· Part 3 provides more technical coverage of BDD practices. We’ll look at techniques for automating acceptance tests in a robust and sustainable way, study a number of BDD tools for different languages and frameworks, and see how BDD helps developers write cleaner, better-designed, higher-quality code. This section is hands-on and practical.

· Part 4 looks the broader picture of BDD in the context of project management, product documentation, reporting, and integration into the build process.

Many of the practical examples in the book will use JVM-based languages and tools, but we’ll also look at examples of BDD tools for .NET, Ruby, Python, and JavaScript. The approaches I’ll describe will be generally applicable to any language.

Because of the broad focus of the book, you may find different sections more or less applicable to your daily work. For example, business analysts might find the material on requirements analysis more relevant than the chapters on coding practices. Table 1 presents a (very) rough guide to the sections various readers might find particularly useful.

Table 1. A rough indicator of the target audience for each section of this book

Prerequisites

The prerequisites for BDD in Action will vary depending on the parts of the book being read.

Parts 1 and 2 (high-level BDD)—These sections require little technical knowledge—they are aimed at all team members, and introduce general principles of BDD. A basic understanding of Agile development practices will be helpful.

Part 3 (low-level BDD/TDD)—This section requires programming knowledge. Many examples are Java-based, but there are also examples in C#, Python, and JavaScript. The general approach is to illustrate concepts and practices with working code, rather than to document any one technology exhaustively. Different technology sections will benefit from a working knowledge of the following technologies:

· Maven —The Java/JVM code samples use Maven, though only a superficial knowledge (the ability to build a Maven project) is required.

· HTML/CSS —The sections on UI testing using Selenium/WebDriver need a basic understanding of how HTML pages are built, what a CSS selector looks like, and, optionally, some familiarity with XPath.

· Restful web services —The sections on testing web services need some understanding of how web services are implemented, and in particular how web service clients are implemented.

· JavaScript —The section on testing JavaScript and JavaScript applications requires a reasonable understanding of JavaScript programming.

Part 4 (Taking BDD further)—This section is general, and has no real technical requirements.

Code conventions

This book contains many source code examples illustrating the various tools and techniques discussed. Source code in listings or in the text appears in a fixed-width font like this. Other related concepts that appear in the text, such as class or variable names, also appear in this font.

Because this book discusses many languages, I’ve made a special effort to keep all of the listings readable and easy to follow, even if you’re not familiar with the language being used. Most of the listings are annotated to make the code easier to follow, and some also have numbered cueballs, indicating particular lines of code that are discussed in the text that follows.

Source code downloads

This book contains many source code examples in a variety of languages. The source code for these examples is available for download on GitHub at https://github.com/bdd-in-action, with a separate subdirectory for each chapter. Some examples are discussed across several chapters—in these cases, each chapter contains the version of the source code discussed in that chapter. The source code can also be downloaded from the publisher’s website at www.manning.com/BDDinAction.

The source code projects don’t contain IDE-specific project files, but they’re laid out in such a way as to make it easy to import them into an IDE.

Solutions to exercises and other resources

There are a number of exercises throughout this book. While they’re primarily designed to get you thinking about the topics under discussion, sample solutions are available on the book’s website at http://bdd-in-action.com. This site also contains links to the tools and libraries used in the book, and other useful related resources