BDD in Action, Second Edition
John Ferguson Smart
  • MEAP began January 2020
  • Publication in Spring 2021 (estimated)
  • ISBN 9781617297533
  • 375 pages (estimated)
  • printed in black & white
free previous edition eBook included
An eBook copy of the previous edition of this book is included at no additional cost. It will be automatically added to your Manning Bookshelf within 24 hours of purchase.

This was by far the best introduction and overview of BDD that I have ever seen.

Lorenzo De Leon
Almost half of all software projects fail to deliver on key requirements. Behavior-Driven Development (BDD) reduces these costly failures by building a shared understanding of how an application should work. Behavior Driven Development in Action, Second Edition teaches communication skills, collaborative practices, and automation tools that ensure everyone from developers to non-technical stakeholders are in agreement on the goals of a project. Revised and expanded in a second edition, the book contains new techniques for incorporating BDD into large-scale development practices such as Agile and DevOps, as well as updating examples for the latest versions of Java.

About the Technology

You can’t write good software if you don’t understand what it’s supposed to do. Behavior-Driven Development (BDD) encourages developers, quality teams, and non-technical stakeholders to collaborate, using conversation and concrete examples to make sure everyone agrees how an application should work and what features really matter. With a body of best practices and sophisticated tools for requirement analysis and test automation, BDD has become a mainstream practice for keeping projects on track and avoiding cancellation.

About the book

Revised and upgraded with the latest tools and practices, Behaviour Driven Development in Action, Second Edition teaches you how to integrate BDD into your software development process. The book starts with the communication skills that are the core of good BDD, showing how a successful requirements analysis will reduce waste and make sure you are developing features in line with business goals. Once you’ve established this collaborative structure, you’ll learn how to use automated acceptance criteria to guide and report on the development process. Alongside learning to apply BDD principles at the coding level for more maintainable code, this new edition is expanded with coverage of working with BDD in large-scale Agile systems and as part of DevOps practices.
Table of Contents detailed table of contents

Part 1: First Steps

1 Building software that makes a difference

1.1 BDD from 50,000 feet

1.2 What problems are you trying to solve?

1.2.1 Building the software right

1.2.2 Building the right software

1.2.3 The knowledge constraint—dealing with uncertainty

1.3 Introducing Behavior-Driven Development

1.3.1 BDD was originally designed as an improved version of TDD

1.3.2 BDD also works well for requirements analysis

1.3.3 BDD principles and practices

1.4 Benefits of BDD

1.4.1 Reduced waste

1.4.2 Reduced costs

1.4.3 Easier and safer changes

1.4.4 Faster releases

1.5 Disadvantages and potential challenges of BDD

1.5.1 BDD requires high business engagement and collaboration

1.5.2 BDD works best in an Agile or iterative context

1.5.3 BDD doesn’t work well in a silo

1.5.4 Poorly written tests can lead to higher test-maintenance costs

1.6 Summary

2 BDD—the whirlwind tour

2.1 The BDD Flow

2.2 Speculate: identifying business value and features

2.2.1 Identifying business objectives

2.2.2 Discovering capabilities and features

2.2.3 Describing features

2.3 Illustrate: exploring a feature with examples

2.3.1 Discovering the feature

2.3.2 Slicing the Feature into User Stories

2.4 Formulate: from examples to executable specifications

2.5 Automate: from executable specifications to automated tests

2.5.1 Setting up a project with Maven and Cucumber

2.5.2 Recording the executable specifications in Cucumber

2.5.3 Automating the executable specifications

2.5.4 Implementing the glue code

2.6 Demonstrate: tests as living documentation

2.7 Maintenance

2.8 Summary

Part 2: What do I want? Defining Requirements

3 Speculate: From business goals to prioritized features

3.1 The Speculate Phase

3.1.1 Strategic Planning in a BDD project

3.1.2 Strategic planning is a continuous activity

3.1.3 Strategic planning involves both stakeholders and team members

3.1.4 Identifying hypotheses and assumptions rather than features

3.2 Describing business vision and goals

3.2.1 Introducing Flying High Airlines

3.2.2 Vision, goals, capabilities and features

3.2.3 What do you want to achieve? Start with a vision

3.2.4 The vision statement

3.2.5 Using vision statement templates

3.2.6 How will it benefit the business? Identify the business goals

3.2.7 Writing good business goals

3.2.8 Show me the money—business goals and revenue

3.2.9 Popping the “why stack”: digging out the business goals

3.3 Impact Mapping

3.3.1 Identify the pain-point

3.3.2 Define the business goal

3.3.3 Who will benefit? Defining the actors

3.3.4 How should their behavior change? Defining the impacts

3.3.5 What should we do about it? Defining the deliverables

3.3.6 Reverse Impact Mapping

3.4 Pirate Canvases

3.4.1 Pirate Metrics

3.4.2 From Pirate Metrics to Pirate Canvases

3.4.3 Discovering what sucks

3.4.4 Building the Epic Landscape

3.5 Summary

4 Describing and prioritizing features

4.1 BDD and Product Backlog Refinement

4.2 What is a “feature”?

4.2.1 Features deliver capabilities

4.2.2 Features can be broken down into more manageable chunks

4.2.3 A feature can be described by one or more user stories

4.2.4 A feature is not a user story

4.2.5 Release Features and Product Features

4.2.6 Not everything fits into a hierarchy

4.3 Real Options: don’t make commitments before you have to

4.3.1 Options have value

4.3.2 Options expire

4.3.3 Never commit early unless you know why

4.4 Deliberate Discovery

4.5 Release and sprint planning with BDD

4.6 Summary

5 Illustrating features with examples

5.1 Introduction – the art of the conversation

5.2 The Three Amigos and other Requirements Discovery workshops

5.3 Illustrating features with examples

5.4 Using tables to describe more complex requirements

5.5 Example Mapping

5.5.1 Example Mapping starts with a User Story

5.5.2 Finding rules and examples

5.5.3 Discovering new rules

5.5.4 Identifying uncertainty

5.5.5 Facilitating an example mapping session

5.6 Feature Mapping

5.6.1 Feature Mapping begins with an example

5.6.2 Examples are broken into steps

5.6.3 Look for variations and new rules

5.6.4 Look for alternate flows

5.7 Summary

6 From examples to executable specifications

6.1 Turning concrete examples into executable scenarios

6.2 Writing executable scenarios

6.2.1 A feature file has a title and a description

6.2.2 Describing the scenarios

6.2.3 The “Given …​ When …​ Then” structure

6.2.4 Ands and buts


6.3 Using tables in scenarios

6.3.1 Using tables in individual steps

6.3.2 Using tables of examples

6.3.3 Pending scenarios

6.4 Organizing your scenarios using feature files and tags

6.4.1 The scenarios go in a feature file

6.4.2 A feature file can contain one or more scenarios

6.4.3 Organizing the feature files

6.4.4 Annotating your scenarios with tags

6.4.5 Provide background and context to avoid duplication

6.5 Expressive scenarios: patterns and anti-patterns

6.5.1 The art of Good Gherkin

6.5.2 What does bad Gherkin look like

6.5.3 Good scenarios are declarative, not imperative

6.5.4 Good scenarios do one thing, and one thing well

6.5.5 Good scenarios have meaningful actors

6.5.6 Good scenarios focus on the essential and hide the incidental

6.5.7 Gherkin scenarios are not test scripts

6.5.8 Good scenarios are independent

6.6 But where are all the details?

6.7 Summary

Part 3: How do I build it? From Specifications to automation

7 Automating the scenarios

8 Designing reliable automated acceptance tests

9 Automating UI-based acceptance criteria

10 More advanced UI automation patterns

11 Automating web services and other non-UI based acceptance criteria

12 BDD and Unit Testing

Part 4: Taking BDD further

13 Living Documentation

14 BDD and large-scale agile

15 BDD and DevOps


Appendix A: Writing executable specifications in .NET with SpecFlow

Appendix B: Writing executable specifications in Python with Behave

Appendix C: Writing executable specifications in TypeScript with Cucumber-JS

What's inside

  • BDD theory and practice
  • How BDD will affect your team
  • BDD for acceptance, integration, and unit testing
  • Automating web services
  • Reporting and living documentation

About the reader

For all development teams. No experience with BDD required. Examples written in Java.

About the author

John Ferguson Smart is a specialist in BDD, automated testing, and software lifecycle development optimization.

placing your order...

Don't refresh or navigate away from the page.
Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
print book $29.99 $49.99 pBook + eBook + liveBook
includes previous edition eBook
Additional shipping charges may apply
BDD in Action, Second Edition (print book) added to cart
continue shopping
go to cart

eBook $24.99 $39.99 3 formats + liveBook
includes previous edition eBook
BDD in Action, Second Edition (eBook) added to cart
continue shopping
go to cart

Prices displayed in rupees will be charged in USD when you check out.

FREE domestic shipping on three or more pBooks