This document discusses Behavior-Driven Development (BDD) using the Gherkin language. BDD focuses on writing testable requirements that can be used by clients, developers, and testers. Requirements are written in Gherkin feature files that contain scenarios describing how software should behave. Scenarios use given, when, then steps to define a test case that can be automatically run by a test runner. The Gherkin language aims to improve communication between teams and ensure the right software is being built according to agreed upon requirements.

1. Behavior-Driven
Development with
Behat and Gherkin
Marcus Moore
1

2. Why Test?
2

3. Types of Tests
• Unit
• Integration
3

4. Test-Driven
Development
4

5. Behavior-Driven
Development
5

6. What is Behavior-Driven
Development?
• Behavior-Driven Development (BDD) is an extension of Test-
Driven Development (TDD) that focuses on delivering
software that matters.
6

7. Why?
• TDD doesn't necessarily mean you built the right thing
• Communication is hard
• Initial requirements document (sometimes)
• Email threads / Slack
• Bug reports
• Github Issues
• Assumptions are made about the requirement
7

8. For Example...
"Users can RSVP for an event if it is not at capacity"
• What if it is at capacity?
• "Put them on a wait-list"
8

9. Gherkin
• Common and human-readable language between clients,
developers, testers, etc
• Write requirements in a way that can be run by a test-runner
9

10. Gherkin
• Clients and developers work off in the same files for
requirements
• Clients are continually signing off on what developers are
working on (if all goes well)
• Maybe adding their own requirements
10

11. Feature Files
• Contain a Story
• Easily understandable
11

12. Feature: one line describing the story
Narrative:
As a [role]
I want [feature]
So that [benefit]
Scenario: [description]
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
12

13. The Steps of a Test
1. Given
2. When
3. Then
13

14. Feature: Creating Events
As an owner of a group
I need to be able to create events
So other users can meet up with me
Rules:
- Only owners can create events for a group
- Events cannot be created in the past
- Events are private until published
Scenario: A non-owner tries to create an event for a group
Given there is an existing group
When a user that is not an owner tries to create an event for the group
Then the user should be rejected with an authorization error
And the event should not exist
Scenario: Create an event with invalid attributes
# ...
Scenario: An owner tries to create an event in the past
# ...
Scenario: Create an event
Given there is an existing group
When the owner tries to create an event for the group
Then the owner should see a success message
And the event should exist
And the event should be private
14

15. The Steps of a Test
1. Given some context
2. When something happens
3. Then there should be a specific outcome
15

16. Example...
16

17. Checklist
• append-snippets
• --suite
• variables
• BaseContext
• BeforeScenarioScope / AfterScenarioScope
17

18. Scenario Backgrounds
Background:
Given there is an existing group
18

19. Scenario Outlines
Scenario Outline: Eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
19

20. Tables
Given there are users:
| username | password | email |
| everzet | 123456 | everzet@knplabs.com |
| fabpot | 22@222 | fabpot@symfony.com |
20

21. Extensions
• There's a lot...
• Mink
21

22. Caveats...
• Debugging isn't as nice
• Code coverage isn't a focus
22

23. Resources
• What is Gherkin – BDD Language?
• What's in a Story?
• The Truth about BDD
23