John Ferguson Smart - BDD in Action [2014, ePub, ENG]

deliberate Discovery—A "Sonnet"
foreword
preface
acknowledgments
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.2.5. Comments
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
index