Behavior-Driven Development with Cucumber
Better Collaboration for Better Software

Master BDD to deliver higher-value software more quickly

To develop high-value products quickly, software development teams need better ways to collaborate. Agile methods like Scrum and Kanban are helpful, but they?re not enough. Teams need better ways to work inside each sprint or work item. Behavior-driven development (BDD) adds just enough structure for product experts, testers, and developers to collaborate more effectively.

Drawing on extensive experience helping teams adopt BDD, Richard Lawrence and Paul Rayner show how to explore changes in system behavior with examples through conversations, how to capture your examples in expressive language, and how to flow the results into effective automated testing with Cucumber. Where most BDD resources focus on test automation, this guide goes deep into how BDD changes team collaboration and what that collaboration looks like day to day. Concrete examples and practical advice will prepare you to succeed with BDD, whatever your context or role.

·         Learn how to collaborate better by using concrete examples of system behavior

·         Identify your project?s meaningful increment of value so you?re always working on something important

·         Begin experimenting with BDD slowly and at low risk

·         Move smoothly from informal examples to automated tests in Cucumber

·         Use BDD to deliver more frequently with greater visibility

·         Make Cucumber scenarios more expressive to ensure you?re building the right thing

·         Grow a Cucumber suite that acts as high-value living documentation

·         Sustainably work with complex scenario data

·         Get beyond the ?mini-waterfalls? that often arise on Scrum teams 

 Chapter 1: Focusing on Value

When Scrum Isn’t Enough

Finding a High-Value Feature to Start With

Before You Start with Cucumber

    Finding the First MMF

    Slicing an MMF into User Stories

Summary

Reference

Chapter 2: Exploring with Examples

BDD Is a Cooperative Game

    BDD Is a Whole Team Thing

    Allow Time and Space to Learn

    Flesh Out the Happy Path First

    Use Real Examples

    Example Mapping Gives the Discussion Structure

    Optimizing for Discovery

Addressing Some Concerns

    Treat Resistance as a Resource

Playing the BDD Game

    Opening

    Exploring

    Closing

Summary

References

Chapter 3: Formalizing Examples into Scenarios

Moving from Examples to Scenarios

    Feature Files as Collaboration Points

    BDD Is Iterative, Not Linear

    Finding the Meaningful Variations

    Gherkin: A Language for Expressive Scenarios

Summary

Resources

Chapter 4: Automating Examples

The Test Automation Stack

Adjusting to Working Test-First

Annotating Element Names in Mockups

How Does User Experience Design Fit In to This?

Did They Really Just Hard Code Those Results?

Anatomy of a Step Definition

Simple Cucumber Expressions

Regular Expressions

    Anchors

    Wildcards and Quantifiers

    Capturing and Not Capturing

    Just Enough

Custom Cucumber Expressions Parameter Types

Beyond Ruby

Slow Is Normal (at First)

Choose Cucumber Based on Audience, Not Scope

Summary

Chapter 5: Frequent Delivery and Visibility

How BDD Changes the Tester’s Role

Exploratory Testing

BDD and Automated Builds

Faster Stakeholder Feedback

How Getting to Done More Often Changes All Sorts of Things

Frequent Visibility and Legacy Systems

Documentation: Integrated and Living

Avoiding Mini-Waterfalls and Making the Change Stick

Summary

References

Chapter 6: Making Scenarios More Expressive

Feedback About Scenarios

How to Make Your Scenarios More Expressive

    Finding the Right Level of Abstraction

    Including the Appropriate Details

    Expressive Language in the Steps

    Refactoring Scenarios

    Good Scenario Titles

Summary

References

Chapter 7: Growing Living Documentation

What Is Living Documentation and Why Is It Better?

Cucumber Features and Other Documentation

Avoid Gherkin in User Story Descriptions

The Unexpected Relationship Between Cucumber Features and User Stories

    Stable Scenarios

Growing and Splitting Features

    Split When Backgrounds Diverge

    Split When a New Domain Concept Emerges

Secondary Organization Using Tags

Structure Is Emergent

Summary

Chapter 8: Succeeding with Scenario Data

Characteristics of Good Scenarios

    Independent

    Repeatable

    Researchable

    Realistic

    Robust

    Maintainable

    Fast

Sharing Data

    When to Share Data

    Raising the Level of Abstraction with Data Personas

Data Cleanup

Summary

Reference

Chapter 9: Conclusion

9780321772633   TOC   4/22/2019

Richard Lawrence is co-owner of the consulting firm Agile For All. He trains and coaches people to collaborate more effectively with other people to solve complex, meaningful problems. He draws on a diverse background in software development, engineering, anthropology, and political science.

Richard was an early adopter of behavior-driven development and led the development of the first .NET version of Cucumber, Cuke4Nuke. He is a popular speaker at conferences on BDD and Agile software development.

Paul Rayner co-founded and co-leads DDD Denver. He regularly speaks at local user groups and at regional and international conferences. If you are looking for an expert hands-on team coach and design mentor in domain-driven design (DDD), BDD with Cucumber, or lean/agile processes, Paul is available for consulting and training through his company, Virtual Genius LLC. 

A¿guide to successfully implementing BDD with today’s #1 testing tool: Cucumber!

• Learn how to create business-facing automated tests that help you develop the right products
• Master the practice and the tool together, without time-consuming mistakes or costly consultants
• Automate functional tests for a wide variety of applications on Ruby, Java, and .NET (with exclusive coverage of Cuke4Duke for Java and Cuke4Nuke for .NET
• For the entire dev team: explains roles of all team members and stakeholders, especially non-developers