Learn how to reap the benefits of behavior-driven development, a collaboration technique that can help your team cohere and deliver higher quality software.

With behavior-driven development (BDD), aka specification by example, you specify your system in terms of automatable examples of its behavior. The many benefits of BDD can include significantly minimized defects, a clear shared understanding of the capabilities/business rules of your system, a definitive criteria for acceptance, and a basis for splitting larger stories.

You’ll want your BDD training tailored to your teams’ needs. Two days training works well for many teams.

The Specification by Example Workshop is one day of hands-on training appropriate for anyone for anyone involved with a software delivery team. In the workshop, you’ll learn what BDD is and more about the benefits it can help you reap. You’ll then learn how to transform user stories into scenarios that can be automated, through a series of exercises that will give you the confidence to implement BDD in your team.

The Specification by Example Dev Workshop is one day of hands-on immersion for team members expected to provide programmatic support for building Cucumber fixtures. It can be delivered for one of several Cucumber implementations environments–whether you’re using Java (CucumberJVM), .NET/C# (SpecFlow), Ruby, Groovy, JavaScript, Clojure, or C++.

Specification by Example Workshop

• Stories, Conversations, Confirmations, and Artifacts

• INVEST

• Cucumber / Gherkin overview

• Specification by Example

• Testing vs. Driving

• Whole Team Collaboration

• Three Amigos

• Goals/Benefits for BDD

• Risks/Challenges of BDD

• The Testing Pyramid: Re-Leveled

• Story Vetting

• Story Breakdown

• Clarifying Scope With Scenarios

• Given-When-Then Phrasing

• Gherkin Feature Files

• Driving Your System With Cucumber

• Grooming and Sustaining

• More on Given-When-Then

• Steps and Stepdefs

• Eliminating Redundancy with Scenario Outlines

• Eliminating Redundancy with Backgrounds

• Scenario Naming Recommendations

• Declarative vs. Imperative Scenarios

• Organizing Features and Scenarios

• Flow Strategy

• Design Principles

• Cucumber Smells

• Overview of Implementing Steps

• Outside-In Development

Specification by Example Dev Workshop

• Where Does Cucumber Fit In?

• What’s in It For Me?

• Cucumber Architecture

• Development Flow

• A First Feature

  • The Gherkin Language

  • Scenarios (stateless!)

  • Implementing Stepdefs

    • Unimplemented Steps

    • Pending Steps

  • Adding an Assertion

  • Running Tests

  • Failing Steps

• Output Formatters

• TDD & BDD

• Directory Structure

• More on Gherkin

• –dry-run

• And, But, … does it matter?

• \* \

• # Comments

• Alternate feature languages

• Regex & Stepdef Matching

• Capturing Arguments

• Debugging

• Background with emphasis on abstraction

• Data tables

  • Inputting data

  • Asserting with

• Scenario Outlines with multiple groups of examples

• Nested steps (Ruby only step delegation–like Scenario Tables in Fitnesse)

• Feature Organization

  • Subfolders: High Level Tasks

  • Running Features in a Subfolder

  • Tags–for documentation & filtering

  • Tag hooks. E.g.: login as admin for a certain scenario. Before, After, Around

  • One-time on start: features/support; At-exit hook

• Challenges & Resolutions

  • Random failures

  • Brittle tests

  • Slow tests

  • Uninvested business

• Dependency chains

• The World

  • minimize instvars

  • helper methods

• Custom type matchers (Ruby: transforms)

• Hooking in

  • Databases

  • Services

  • UIs

• Integrating

  • Project / File organization

  • Command-line interface

  • Profiles / YML config

  • WIP flow – @wip tag