Behavior-Driven Development with Cucumber: Better Collaboration for Better Software

Auteur

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.

Texte du rabat

AcceptanceTest-Driven Development with Cucumber fills the gap between creating business-facing automated tests that support the development of the right product and accomplishing the task with Cucumber, which is rapidly becoming the most popular tool. Richard Lawrence and Paul Rayner begin by illuminating ATDD's value, and showing how it can help you produce better software with less pain. Next, they present a complete ATDD/Cucumber reference and tutorial that provides a common language for software customers and team members alike. Lawrence and Rayner thoroughly explain the role of each team member and stakeholder, with a particularly insightful emphasis on non-developers. Next, they show how to automate functional tests for web, console, native client, legacy, and other applications on the Ruby, Java, and .NET. platforms. To complement the Web's existing Ruby-oriented Cucumber resources, the authors provide even more Java (Cuke4Duke) and C# (Cuke4Nuke) examples.

Résumé

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

Contenu

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