The Behaviour Specification Handbook
As a long-time advocate of Behaviour-Driven Development (BDD) and having been a technical lead and coach of BDD enterprise software development teams since 2010, I have tried many different variations of the process of BDD and the writing and implementation of Behaviour Specifications.
This handbook is my suggested practical, prescriptive methodology for writing Behaviour Specifications (also known as 'scenarios' in the Gherkin language), including tips and suggestions that have repeatedly proven to me to be worthwhile practices in both small and large-scale solutions.
I hope they help you and your team to write better Behaviour Specifications and deliver successful solutions!
Table of Contents
- Overview Of Behaviour-Driven Development (BDD)
- Scaling BDD To Large Solutions
- What Is A Software Component?
- What Are Behaviour Specifications?
- No Other Test Cases Are Necessary!
- Developers: No Other Automated Tests!
- Overview Of The Gherkin Language
- Thoughts On Gauge
- Feature Files
- Feature Names
- What Is A Behaviour Specification Description?
- The Behaviour Specification Writing Meeting
- Meeting Milestone 1 — Background Context and Requirements Overview
- Meeting Milestone 2 — Technical Design Overview
- Meeting Milestone 3 — Checkpoint
- What's Happening In Our Minds?
- Meeting Milestone 4 — Behaviour Identification
- Meeting Milestone 5 — Step Writing
- Meeting Milestone 6 — Determine Test Types
- About End-To-End Behaviours
- About Outsourcing Delivery
- The Software Component Context Is King
- Avoid Specifying Internal Technical Implementation Details
- Specify Relevant Business Capabilities
- Specify Component Interaction Behaviours
- Write One Specification For One Behaviour
- Use Present Tense
- Avoid Generic Verbs
- Write In Everyday Business Language
- SpecFlow/Cucumber Is Only The Name Of A Tool
- Have Different Feature Files For Different User Interfaces
- Start With Should
- Indicate Positive or Negative Behaviour
- Indicate Primary or Secondary Behaviour
- Unique Within Their Feature File
- Unique Without Their Feature File
- Follow This Template
- Work Backwards: Then-When-Given
- Avoid "I"
- Terminology Guidelines
- Reuse Steps, If Possible
- Understand Technical Tool Constraints
- Single When
- Guidelines For Examples and Data Tables
- Behaviour Specifications Before Implementation
- The Roles Of Developers and Test Analysts
- Identify Which Developers Will Code Each Behaviour
- Identify Who Will Code The Automation Or Manually Perform Each Test
- Separate Implementation Of Unit Test Steps From Integration Test Steps
- Review Test Outputs