BDD in Action
Behavior-Driven Development for the whole software lifecycle
John Ferguson Smart
Foreword by Dan North
  • September 2014
  • ISBN 9781617291654
  • 384 pages
  • printed in black & white

Delivers a thorough treatment of the current state of BDD tools.

Dan North, Creator of BDD

BDD in Action teaches you the Behavior-Driven Development model and shows you how to integrate it into your existing development process. First you'll learn how to apply BDD to requirements analysis to define features that focus your development efforts on underlying business goals. Then, you'll discover how to automate acceptance criteria and use tests to guide and report on the development process. Along the way, you'll apply BDD principles at the coding level to write more maintainable and better documented code.

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 teams to use conversation and concrete examples to build up a shared understanding of how an application should work and which features really matter. With an emerging body of best practices and sophisticated new tools that assist in requirement analysis and test automation, BDD has become a hot, mainstream practice.

Table of Contents detailed table of contents

Deliberate Discovery—A "Sonnet"




about this book

about the cover illustration

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. Introducing the train timetable application

2.2. Determining the value proposition of the application

2.3. Requirements analysis: discovering and understanding features

2.3.1. Describing features

2.3.2. Breaking features down into stories

2.3.3. Illustrating the stories with examples

2.4. Implementation: building and delivering features

2.4.1. Going from examples to acceptance criteria

2.4.2. Setting up Maven and Git

2.4.3. Executable specifications: automating the acceptance criteria

2.4.4. Automated tests: implementing the acceptance criteria

2.4.5. Tests as living documentation

2.5. Maintenance

2.6. Summary

Part 2 What do I want? Defining requirements using BDD

3. Understanding the business goals: Feature Injection and related techniques

3.1. Introducing Flying High Airlines

3.2. Feature Injection

3.2.1. Hunt the value

3.2.2. Inject the features

3.2.3. Spot the examples

3.2.4. Putting it all together

3.3. What do you want to achieve? Start with a vision

3.3.1. The vision statement

3.3.2. Using vision statement templates

3.4. How will it benefit the business? Identify the business goals

3.4.1. Writing good business goals

3.4.2. Show me the money—business goals and revenue

3.4.3. Popping the "why stack": digging out the business goals

3.5. Who will benefit? Identify stakeholders and their needs

3.6. What do you need to build? Identify capabilities

3.7. What features will provide the most ROI? The Purpose-Based Alignment Model

3.7.1. Differentiating features

3.7.2. Parity features

3.7.3. Partner features

3.7.4. Minimum impact

3.8. Summary

4. Defining and illustrating features

4.1. What is a "feature"?

4.1.1. Features deliver capabilities

4.1.2. Features can be broken down into more manageable chunks

4.1.3. A feature can be described by one or more user stories

4.1.4. A feature is not a user story

4.1.5. Epics are really big user stories

4.1.6. Not everything fits into a hierarchy

4.2. Illustrating features with examples

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. From examples to working software: the bigger picture

4.6. Summary

5. From examples to executable specifications

5.1. Turning concrete examples into executable scenarios

5.2. Writing executable scenarios

5.2.1. A feature file has a title and a description

5.2.2. Describing the scenarios

5.2.3. The "Given …​ When …​ Then" structure

5.2.4. Ands and buts


5.3. Using tables in scenarios

5.3.1. Using tables in individual steps

5.3.2. Using tables of examples

5.4. Expressive scenarios: patterns and anti-patterns

5.4.1. Writing expressive Given steps

5.4.2. Writing expressive When steps

5.4.3. Writing expressive Then steps

5.4.4. Providing background and context

5.4.5. Avoid dependencies between scenarios

5.5. Organizing your scenarios using feature files and tags

5.5.1. The scenarios go in a feature file

5.5.2. A feature file can contain one or more scenarios

5.5.3. Organizing the feature files

5.5.4. Annotating your scenarios with tags

5.6. Summary

6. Automating the scenarios

6.1. Introduction to automating scenarios

6.1.1. Step definitions interpret the steps

6.1.2. Keep the step definition methods simple

6.2. Implementing step definitions: general principles

6.2.1. Installing BDD tools

6.2.2. Implementing step definitions

6.2.3. Passing parameters to step implementations

6.2.4. Maintaining state between steps

6.2.5. Using table data from step definitions

6.2.6. Implementing example-based scenarios

6.2.7. Understanding scenario outcomes

6.3. Implementing BDD more effectively with Thucydides

6.4. Automating scenarios in Java with JBehave

6.4.1. Installing and setting up JBehave

6.4.2. JBehave step definitions

6.4.3. Sharing data between steps

6.4.4. Passing tables to steps

6.4.5. Step definitions for tables of examples

6.4.6. Pattern variants

6.4.7. Failures and errors in the scenario outcomes

6.5. Automating scenarios in Java using Cucumber-JVM

6.5.1. Cucumber-JVM project setup and structure

6.5.2. Cucumber-JVM step definitions

6.5.3. Pattern variants

6.5.4. Passing tables to steps

6.5.5. Step definitions for tables of examples

6.5.6. Sharing data between steps

6.5.7. Pending steps and step outcomes

6.6. Automating scenarios in Python with Behave

6.6.1. Installing Behave

6.6.2. The Behave project structure

6.6.3. Behave step definitions

6.6.4. Combining steps

6.6.5. Step definitions using embedded tables

6.6.6. Step definitions for tables of examples

6.6.7. Running scenarios in Behave

6.7. Automating scenarios in .NET with SpecFlow

6.7.1. Setting up SpecFlow

6.7.2. Adding feature files

6.7.3. Running scenarios

6.7.4. SpecFlow step definitions

6.7.5. Sharing data between steps

6.7.6. Step definitions using example tables

6.8. Automating scenarios in JavaScript with Cucumber-JS

6.8.1. Setting up Cucumber-JS

6.8.2. Writing feature files in Cucumber-JS

6.8.3. Implementing the steps

6.8.4. Running the scenarios

6.9. Summary

Part 3 How do I build it? Coding the BDD way

7. From executable specifications to rock-solid automated acceptance tests

7.1. Writing industrial-strength acceptance tests

7.2. Automating your test setup process

7.2.1. Initializing the database before each test

7.2.2. Initializing the database at the start of the test suite

7.2.3. Using initialization hooks

7.2.4. Setting up scenario-specific data

7.2.5. Using personas and known entities

7.3. Separating the what from the how

7.3.1. The Business Rules layer describes the expected outcomes

7.3.2. The Business Flow layer describes the user’s journey

7.3.3. The Technical layer interacts with the system

7.3.4. How many layers?

7.4. Summary

8. Automating acceptance criteria for the UI layer

8.1. When and how should you test the UI?

8.1.1. The risks of too many web tests

8.1.2. Web testing with headless browsers

8.1.3. How much web testing do you really need?

8.2. Automating web-based acceptance criteria using Selenium WebDriver

8.2.1. Getting started with WebDriver in Java

8.2.2. Identifying web elements

8.2.3. Interacting with web elements

8.2.4. Working with asynchronous pages and testing AJAX applications

8.2.5. Writing test-friendly web applications

8.3. Using page objects to make your tests cleaner

8.3.1. Introducing the Page Objects pattern

8.3.2. Writing well-designed page objects

8.3.3. Using libraries that extend WebDriver

8.4. Summary

9. Automating acceptance criteria for non-UI requirements

9.1. Balancing UI and non-UI acceptance tests

9.2. When to use non-UI acceptance tests

9.3. Types of non-UI automated acceptance tests

9.3.1. Testing against the controller layer

9.3.2. Testing business logic directly

9.3.3. Testing the service layer

9.4. Defining and testing nonfunctional requirements

9.5. Discovering the design

9.6. Summary

10. BDD and unit testing

10.1. BDD, TDD, and unit testing

10.1.1. BDD is about writing specifications, not tests, at all levels

10.1.2. BDD builds on established TDD practices

10.1.3. BDD unit-testing tools are there to help

10.2. Going from acceptance criteria to implemented features

10.2.1. BDD favors an outside-in development approach

10.2.2. Start with a high-level acceptance criterion

10.2.3. Automate the acceptance criteria scenarios

10.2.4. Implement the step definitions

10.2.5. Understand the domain model

10.2.6. Write the code you’d like to have

10.2.7. Use the step definition code to specify and implement the application code

10.2.8. How did BDD help?

10.3. Exploring low-level requirements, discovering design, and implementing more complex functionality

10.3.1. Use step definition code to explore low-level design

10.3.2. Working with tables of examples

10.3.3. Discover new classes and services as you implement the production code

10.3.4. Implement simple classes or methods immediately

10.3.5. Use a minimal implementation

10.3.6. Use stubs and mocks to defer the implementation of more complex code

10.3.7. Expand on low-level technical specifications

10.4. Tools that make BDD unit testing easier

10.4.1. Practicing BDD with traditional unit-testing tools

10.4.2. Writing specifications, not tests: the RSpec family

10.4.3. Writing more expressive specifications using Spock or Spec2

10.5. Using executable specifications as living documentation

10.5.1. Using fluent coding to improve readability

10.5.2. Fluent assertions in JavaScript

10.5.3. Fluent assertions in static languages

10.6. Summary

Part 4 Taking BDD Further

11. Living Documentation: reporting and project management

11.1. Living documentation: a high-level view

11.2. Are we there yet? Reporting on feature readiness and feature coverage

11.2.1. Feature readiness: what features are ready to deliver

11.2.2. Feature coverage: what requirements have been built

11.3. Integrating a digital product backlog

11.4. Organizing the living documentation

11.4.1. Organizing living documentation by high-level requirements

11.4.2. Organizing living documentation using tags

11.4.3. Living documentation for release reporting

11.5. Providing more free-form documentation

11.6. Technical living documentation

11.6.1. Unit tests as living documentation

11.6.2. Living Documentation for legacy applications

11.7. Summary

12. BDD in the build process

12.1. Executable specifications should be part of an automated build

12.1.1. Each specification should be self-sufficient

12.1.2. Executable specifications should be stored under version control

12.1.3. You should be able to run the executable specifications from the command line

12.2. Continuous integration speeds up the feedback cycle

12.3. Continuous delivery: any build is a potential release

12.4. Continuous integration used to deploy living documentation

12.4.1. Publishing living documentation on the build server

12.4.2. Publishing living documentation to a dedicated web server

12.5. Faster automated acceptance criteria

12.5.1. Running parallel acceptance tests within your automated build

12.5.2. Running parallel tests on multiple machines

12.5.3. Running parallel web tests using Selenium Grid

12.6. Summary

12.7. Final words


What's inside

  • BDD theory and practice
  • How BDD will affect your team
  • BDD for acceptance, integration, and unit testing
  • Examples in Java, .NET, JavaScript, and more
  • Reporting and living documentation

About the reader

No prior experience with BDD is required.

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.
print book $29.99 $49.99 pBook + eBook + liveBook
Additional shipping charges may apply
Prints and ships within 3-5 days
BDD in Action (print book) added to cart
continue shopping
go to cart

eBook $31.99 $39.99 3 formats + liveBook
BDD in Action (eBook) added to cart
continue shopping
go to cart

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

This book 1-hop 2-hops 3-hops

FREE domestic shipping on three or more pBooks