BDD in Action Behavior-Driven Development for the Whole Software Lifecycle
In BDD in Action, Second Edition, you'll learn to seamlessly integrate BDD into your existing development process. This thoroughly revised new edition now shows how to integrate BDD with DevOps and large-scale Agile systems. Practical examples introduce cross-functional team communication skill...
Otros Autores: | , , |
---|---|
Formato: | Libro electrónico |
Idioma: | Inglés |
Publicado: |
Shelter Island, NY :
Manning
[2023]
|
Edición: | Second edition |
Materias: | |
Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009748738506719 |
Tabla de Contenidos:
- Intro
- inside front cover
- BDD in Action
- Praise for the first edition
- Copyright
- dedication
- Deliberate Discovery-A "Sonnet"
- contents
- front matter
- foreword
- preface
- acknowledgments
- about this book
- Who should read this book
- How the book is organized: A road map
- Prerequisites
- About the code
- Source code and other resources
- liveBook discussion forum
- about the authors
- 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 Is BDD right for your projects?
- 1.4 What you will learn in this book
- Summary
- 2 Introducing Behavior-Driven Development
- 2.1 BDD was originally designed to make teaching TDD easier
- 2.2 BDD also works well for requirements analysis
- 2.3 BDD principles and practices
- 2.3.1 Focus on features that deliver business value
- 2.3.2 Work together to specify features
- 2.3.3 Embrace uncertainty
- 2.3.4 Illustrate features with concrete examples
- 2.3.5 A Gherkin primer
- 2.3.6 Don't write automated tests
- write executable specifications
- 2.3.7 These principles also apply to unit tests
- 2.3.8 Deliver living documentation
- 2.3.9 Use living documentation to support ongoing maintenance work
- 2.4 Benefits of BDD
- 2.4.1 Reduced waste
- 2.4.2 Reduced costs
- 2.4.3 Easier and safer changes
- 2.4.4 Faster releases
- 2.5 Disadvantages and potential challenges of BDD
- 2.5.1 BDD requires high business engagement and collaboration
- 2.5.2 BDD works best in an Agile or iterative context
- 2.5.3 BDD doesn't work well in a silo
- 2.5.4 Poorly written tests can lead to higher test-maintenance costs
- Summary.
- 3 BDD: The whirlwind tour
- 3.1 The BDD flow
- 3.2 Speculate: Identifying business value and features
- 3.2.1 Identifying business objectives
- 3.2.2 Discovering capabilities and features
- 3.2.3 Describing features
- 3.3 Illustrate: Exploring a feature with examples
- 3.3.1 Discovering the feature
- 3.3.2 Slicing the feature into User Stories
- 3.4 Formulate: From examples to executable specifications
- 3.5 Automate: From executable specifications to automated tests
- 3.5.1 Setting up a project with Maven and Cucumber
- 3.5.2 Recording the executable specifications in Cucumber
- 3.5.3 Automating the executable specifications
- 3.5.4 Implementing the glue code
- 3.6 Demonstrate: Tests as living documentation
- 3.7 BDD reduces maintenance costs
- Summary
- Part 2. What do I want? Defining requirements using BDD
- 4 Speculate: From business goals to prioritized features
- 4.1 The Speculate phase
- 4.1.1 Strategic Planning in a BDD project
- 4.1.2 Strategic Planning is a continuous activity
- 4.1.3 Strategic Planning involves both stakeholders and team members
- 4.1.4 Identifying hypotheses and assumptions rather than features
- 4.2 Describing business vision and goals
- 4.2.1 Vision, goals, capabilities, and features
- 4.2.2 What do you want to achieve? Start with a vision
- 4.2.3 The vision statement
- 4.2.4 Using vision statement templates
- 4.2.5 How will it benefit the business? Identify the business goals
- 4.2.6 Writing good business goals
- 4.2.7 Show me the money: Business goals and revenue
- 4.2.8 Popping the "why stack": Digging out the business goals
- 4.3 Impact Mapping
- 4.3.1 Identify the pain point
- 4.3.2 Define the business goal
- 4.3.3 Who will benefit? Defining the actors
- 4.3.4 How should their behavior change? Defining the impacts
- 4.3.5 What should we do about it? Defining the deliverables.
- 4.3.6 Reverse Impact Mapping
- 4.4 Pirate Canvases
- 4.4.1 Pirate Metrics
- 4.4.2 From Pirate Metrics to Pirate Canvases
- 4.4.3 Discovering what sucks
- 4.4.4 Building the Epic Landscape
- Summary
- 5 Describing and prioritizing features
- 5.1 BDD and Product Backlog Refinement
- 5.2 What is a feature?
- 5.2.1 Features deliver capabilities
- 5.2.2 Features can be broken down into more manageable chunks
- 5.2.3 A feature can be described by one or more User Stories
- 5.2.4 A feature is not a User Story
- 5.2.5 Release features and product features
- 5.2.6 Not everything fits into a hierarchy
- 5.3 Real Options: Don't make commitments before you have to
- 5.3.1 Options have value
- 5.3.2 Options expire
- 5.3.3 Never commit early unless you know why
- 5.4 Deliberate Discovery
- 5.5 Release and sprint planning with BDD
- Summary
- 6 Illustrating features with examples
- 6.1 The Three Amigos and other requirements discovery workshops
- 6.2 Illustrating features with examples
- 6.3 Using tables to describe more complex requirements
- 6.4 Example Mapping
- 6.4.1 Example Mapping starts with a User Story
- 6.4.2 Finding rules and examples
- 6.4.3 Discovering new rules
- 6.4.4 Surfacing uncertainty
- 6.4.5 Facilitating an Example Mapping session
- 6.5 Feature Mapping
- 6.5.1 Feature Mapping begins with an example
- 6.5.2 Examples are broken into steps
- 6.5.3 Look for variations and new rules
- 6.5.4 Look for alternate flows
- 6.5.5 Grouping related flows and recording uncertainty
- 6.6 OOPSI
- 6.6.1 Outcomes
- 6.6.2 Outputs
- 6.6.3 Process
- 6.6.4 Scenarios
- 6.6.5 Inputs
- Summary
- 7 From examples to executable specifications
- 7.1 Turning concrete examples into executable scenarios
- 7.2 Writing executable scenarios
- 7.2.1 A feature file has a title and a description
- 7.2.2 Describing the scenarios.
- 7.2.3 The Given ... When ... Then structure
- 7.2.4 Ands and buts
- 7.2.5 Comments
- 7.3 Using tables in scenarios
- 7.3.1 Using tables in individual steps
- 7.3.2 Using tables of examples
- 7.3.3 Pending scenarios
- 7.4 Organizing your scenarios using feature files and tags
- 7.4.1 The scenarios go in a feature file
- 7.4.2 A feature file can contain one or more scenarios
- 7.4.3 Organizing the feature files
- 7.4.4 Using a flat directory structure
- 7.4.5 Organizing feature files by stories or product increments
- 7.4.6 Organizing feature files by functionality and capability
- 7.4.7 Annotating your scenarios with tags
- 7.4.8 Provide background and context to avoid duplication
- 7.5 Rules and examples
- 7.6 Expressive scenarios: Patterns and anti-patterns
- 7.6.1 The art of good Gherkin
- 7.6.2 What bad Gherkin looks like
- 7.6.3 Good scenarios are declarative, not imperative
- 7.6.4 Good scenarios do one thing, and one thing well
- 7.6.5 Good scenarios have meaningful actors
- 7.6.6 Good scenarios focus on the essential and hide the incidental
- 7.6.7 Gherkin scenarios are not test scripts
- 7.6.8 Good scenarios are independent
- 7.7 But where are all the details?
- Summary
- Part 3. How do I build it? Coding the BDD way
- 8 From executable specifications to automated acceptance tests
- 8.1 Introduction to automating scenarios
- 8.1.1 Step definitions interpret the steps
- 8.2 Setting up your project
- 8.2.1 Setting up a Cucumber project in Java or TypeScript
- 8.2.2 Organizing a Cucumber project in Java
- 8.2.3 Organizing a Cucumber project in TypeScript
- 8.3 Running Cucumber scenarios
- 8.3.1 Cucumber test runner classes in Java
- 8.3.2 Running Cucumber scenarios in JavaScript and TypeScript
- 8.4 Writing glue code
- 8.4.1 Injecting data with step definition parameters.
- 8.4.2 Making your Cucumber Expressions more flexible
- 8.4.3 Cucumber Expressions and custom parameter types
- 8.4.4 Using regular expressions
- 8.4.5 Working with lists and data tables
- 8.5 Setting up and tearing down with backgrounds and hooks
- 8.5.1 Using background steps
- 8.5.2 Using hooks
- 8.6 Preparing your test environments using hooks
- 8.6.1 Using in-memory databases
- 8.7 Using virtual test environments
- 8.7.1 Using TestContainers to manage Docker containers for your tests
- Summary
- 9 Writing solid automated acceptance tests
- 9.1 Writing industrial-strength acceptance tests
- 9.2 Using personas and known entities
- 9.2.1 Working with persona in your scenarios
- 9.2.2 Storing persona data in HOCON
- 9.3 Layers of abstraction
- 9.3.1 The Business Rules layer describes the expected outcomes
- 9.3.2 The Business Flow layer describes the user's journey
- 9.3.3 Business tasks interact with the application or with other tasks
- 9.3.4 The Technical layer interacts with the system
- Summary
- 10 Automating acceptance criteria for the UI layer
- 10.1 When and how should you test the UI?
- 10.2 Where does UI testing fit in your test automation strategy?
- 10.2.1 Which scenarios should be implemented as UI tests?
- 10.2.2 Illustrating user journeys
- 10.2.3 Illustrating business logic in the user interface
- 10.2.4 Documenting and verifying screen-specific business logic
- 10.2.5 Showing how information is rendered in the user interface
- 10.2.6 Automating web-based acceptance criteria using Selenium WebDriver
- 10.2.7 Getting started with WebDriver in Java
- 10.2.8 Setting up a WebDriver driver
- 10.2.9 Integrating WebDriver with Cucumber
- 10.2.10 Sharing WebDriver instances between step definition classes
- 10.2.11 Interacting with the web page
- 10.2.12 How to locate elements on a page.
- 10.2.13 Interacting with web elements.