1. Living Requirements using Behavior Driven Development
May 8, 2015

2. Behavior-Driven Development (BDD)
Outline
Behavior-Driven Development (BDD)
What is it?
What are the benefits?
Who participates?
Rhythm of BDD
How does it fit in the agile process?
Gherkin language to create living requirements
How do we define system behavior?
BDD Live Demo

3. Behavior-Driven Development
What is BDD?
Behavior-Driven Development (BDD) is a disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior, also known as, acceptance criteria for the feature that is about to implemented

4. Behavior-Driven Development
What is BDD?
Behavior-Driven Development (BDD) is a disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior, also known as, acceptance criteria for the feature that is about to implemented
A.K.A.
Acceptance Test Driven Development
Specification by Example
Story Testing
Functional Testing

5. Behavior-Driven Development
Shared Understanding Made into Automated Tests
SHARED UNDERSTANDING
The biggest challenge in software development is to understand what the customer REALLY needs, in detail.
GIVEN <condition>
We use a special text syntax called Gherkin to build scenarios…
Behavior-Driven Development (BDD) encourages creating a shared understanding and collaboration by writing simple, scenario-based, single-source, living specifications that business people and IT people can read, easily understand, and quickly agree to that provides clear traceability.
THEN <result>
WHEN <action>
Using a tool called Cucumber, the previously written specifications can actually be turned into executable tests.
The most difficult part of DONEness is to ensure that your story has been fully tested so that it satisfies everything the Product Owner asked for and works when integrated with the rest of the product.
AUTOMATED TESTING
Thus, the language of our shared understanding becomes the language of our tests as well.
Living Specification

6. Behavior-Driven Development
Shared Understanding Made into Automated Tests
It’s ALIVE!
Living Specification
SHARED UNDERSTANDING
The biggest challenge in software development is to understand what the customer REALLY needs, in detail.
GIVEN <condition>
We use a special text syntax called Gherkin to build scenarios…
Behavior-Driven Development (BDD) encourages creating a shared understanding and collaboration by writing simple, scenario-based, single-source, living specifications that business people and IT people can read, easily understand, and quickly agree to that provides clear traceability.
THEN <result>
WHEN <action>
Using a tool called Cucumber, the previously written specifications can actually be turned into executable tests.
The most difficult part of DONEness is to ensure that your story has been fully tested so that it satisfies everything the Product Owner asked for and works when integrated with the rest of the product.
AUTOMATED TESTING
Thus, the language of our shared understanding becomes the language of our tests as well.
It’s Alive!

7. The Building Blocks to Agile Scrum Software Development
Gherkin
Given (Context or Event)
When (User Action)
Then (Outcome)
Feature
Background
Scenario
Given
When
Then
And
But *
Scenario Outline
Examples
This is a commonly used format for writing Acceptance Criteria.
Given-When-Then describes the scenario in chronological order.
The GIVEN clause
The given clause sets up the initial state for the scenario we are testing.
It should be expressed as a pre-existing condition
It should not be expressed like an action
GIVEN a registered user ‘Bob‘ <Good>
GIVEN a registered user 'bob' has signed in <Not Good>
The WHEN clause
The when clause describes the things that the user (or some other actor) does to the system.
It should describe what the user does
It should not describe things that the system does
WHEN a user navigates to the Sign In page AND the user signs in as 'bob‘ <Good>
WHEN the profile page for 'bob' is displayed <Not Good>
The THEN clause
The then clause describes the things that the system is expected to do. ( in response to something done in a when clause)
It should describe what the system should do
It should not describe things that the user does
THEN the username 'bob' will be displayed <Good>
THEN the user signs in as 'bob‘ <Not Good>
Source:

8. The Building Blocks to Agile Scrum Software Development
Gherkin
Given (Context or Event)
When (User Action)
Then (Outcome)
Consumed by Cucumber
Originally Ruby
Cucubmer-JVM (java)
Specflow (.NET)
This is a commonly used format for writing Acceptance Criteria.
Given-When-Then describes the scenario in chronological order.
The GIVEN clause
The given clause sets up the initial state for the scenario we are testing.
It should be expressed as a pre-existing condition
It should not be expressed like an action
GIVEN a registered user ‘Bob‘ <Good>
GIVEN a registered user 'bob' has signed in <Not Good>
The WHEN clause
The when clause describes the things that the user (or some other actor) does to the system.
It should describe what the user does
It should not describe things that the system does
WHEN a user navigates to the Sign In page AND the user signs in as 'bob‘ <Good>
WHEN the profile page for 'bob' is displayed <Not Good>
The THEN clause
The then clause describes the things that the system is expected to do. ( in response to something done in a when clause)
It should describe what the system should do
It should not describe things that the user does
THEN the username 'bob' will be displayed <Good>
THEN the user signs in as 'bob‘ <Not Good>
Source:

9. Behavior-Driven Development
Like Test-Driven Development (TDD) but with Different Scope
Test from the “outside-in”
TDD fails when algorithm doesn’t exist (inside-out)
Executable specification fails because a feature doesn’t exist
Helps teams build the right software product, complementing technical practices that ensure that the product is built right

10. An Example Seems clear, but is it? Much more definitive
Customer should be prevented from entering invalid credit card information
Much more definitive
If a customer enters a credit card number that isn’t exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.
The Cucumber Book, Matt Wynne & Aslak Hellesoy

11. Rhythm of BDD System Behavior Safety Net First “User”
The system behavior is defined by a group of scenarios that let you quickly add slices of functionality to help learn about the feature and it’s affect throughout the system
Safety Net
The behavioral tests act as a safety net that allows us to make functional and structural improvements to the code more freely without introducing bugs
First “User”
The tests act as the first “User” of the code. This results in code that is more easily reusable

12. Benefits of BDD Usability Live Documentation
System functionality is more deliberate
Developer is placed into the paradigm of a user of the system
Fewer defects
Live Documentation
Living specifications
Tests describe the behavior of the system

13. Benefits of BDD Higher Code Quality Confidence
Testable code tends to follow better design patterns
Modularized
Flexible
Understandable
Testable code tends to have fewer lines
Confidence
Tests cover smaller, incremental slices of the system making it easier to pivot or grow a feature
Tests act as a safety net covering existing functionality

14. Benefits of BDD Faster Delivery
Tests allow new features to be added more easily without breaking existing ones
Misunderstanding of requirements appear earlier in the development cycle and are more quickly eliminated – less time debugging.

15. Behavior-Driven Development
Living Specifications with the Gherkin Language
Gherkin defines example Scenarios in a Given-When-Then format to create structure around the behaviors so that they can be automated
Gherkin gives us a lightweight structure for documenting examples of the behavior our stakeholders want, in a way that it can be easily understood both by the stakeholders and by Cucumber
Gherkin only has a few keywords allowing the team to build a domain specific language (DSL) for common use in the system and in conversations to promote a shared understanding
Gherkin uses user defined tags to organize scenarios
@web

16. Feature discussion with PO
Me Likey
Huh?
OUTSIDE-IN INSIDE-OUT

17. A Basic Example using Gherkin: Check inbox
This scenario is good but has a lot of detail that makes it hard to read
Scenario: Check inbox
Given a User "Dave" with password "password”
And a User "Sue" with password "secret"
And an to "Dave" from "Sue"
When I sign in as "Dave" with password "password"
Then I should see 1 from "Sue" in my inbox
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

18. A Basic Example using Gherkin: Check inbox
Let’s get rid of the incidental details, the password in this case.
Scenario: Check inbox
Given a User "Dave"
And a User "Sue"
And an to "Dave" from "Sue"
When I sign in as "Dave"
Then I should see 1 from "Sue" in my inbox
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

19. A Basic Example using Gherkin: Check inbox
Let’s remove even more noise. This is very readable and easy to maintain
Scenario: Check inbox
Given I have received an from "Sue"
When I sign in
Then I should see 1 from "Sue" in my inbox
That’s exactly what I meant!! What a great scenario.
I’m a great Product Owner!
Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

20. David Gijsbers, Eliassen Group

21. Lifecycle of a User Story
Iteration 1: PO creates user story and bulleted acceptance criteria
Iteration 2: 3 Amigos groom the story adding Given…When…Then scenarios
Iteration 3: Developer & tester work the story using cucumber to generate the automation framework. They use the red-green-refactor cycle to design, develop, and test the feature
Note: Other artifacts can and should be attached to the user story such as, design documents, s, or anything else that helps clarify the intent of the user story

22. Behavior-Driven Development
A disciplined technique for building software in which the Product Owner, a Programmer, and a Tester collaborate on system behavior
Marty Bradley

23. Some Tools and Helpful Links
Cucumber-JVM is a native Java implementation of Cucumber
Specflow is a .NET implementation of Cucumber
- Cucumber main
- Online collaboration version
- My blog containing some BDD videos