Living Requirements using Behavior Driven Development May 8, 2015 http://www.linkedin.com/in/martybradley

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

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

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

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

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!

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: http://www.jroller.com/perryn/entry/given_when_then_and_how

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: http://www.jroller.com/perryn/entry/given_when_then_and_how

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

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

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

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

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

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.

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 @fast, @overnight, @web

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

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 email to "Dave" from "Sue" When I sign in as "Dave" with password "password" Then I should see 1 email from "Sue" in my inbox Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

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 email to "Dave" from "Sue" When I sign in as "Dave" Then I should see 1 email from "Sue" in my inbox Example from The Cucumber Book, Matt Wynne & Aslak Hellesoy

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 email from "Sue" When I sign in Then I should see 1 email 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

David Gijsbers, Eliassen Group

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, emails, or anything else that helps clarify the intent of the user story

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 www.bradasphere.com www.linkedin.com/in/martybradley

Some Tools and Helpful Links Cucumber-JVM is a native Java implementation of Cucumber Specflow is a .NET implementation of Cucumber https://cukes.info/ - Cucumber main https://cucumber.pro/ - Online collaboration version http://bradasphere.com/ - My blog containing some BDD videos