Delivering a fully end-to-end tested product which verifiably produces value might sound like a bit of a dream. Behavior driven development ensures that each feature is formally defined (think automated testing) and directly related to a business goal.

The steps are as follows:

Start with a goal Identify actors and what they do that relates them to the goal Identify the behaviors which the actors must perform Identify features which enable the behavior and assess the value/complexity of each Write feature specifications with examples to remove ambiguity

Interesting to point out that we barely talk about programming directly in this article. Also interesting: these slides on BDD

S.M.A.R.T. Goals

Specific, measurable, attainable, relevant, and time-bound.

Consider the following:

100 purple widget sales through the website by the end of December 2015

vs

Sell a good number of widgets through the site

The first goal makes it so you feel good about selling 101 purple widgets in November, where the second goal is a little less certain.

Selecting your Actors

Actors are people with behaviors that affect the goal.

Sticking with our purple widgets example, we have:

buyers of the widgets

of the widgets site admins

warehouse distribution center

distribution center finance department

Buyers, admins, warehouse, and finance.

Valuable Behaviors

What is the behavior of the buyers that relate them to the goal? Well, they buy things. In order to buy things, they must see things and be able to click on them. We might describe the behaviors of our actors as follows:

Buyers: See three purple widgets featured on homepage Browse featured widgets Navigate between widget categories See widget thumbnails on category view See widget details

Admins: Login on a private page add widgets remove widgets update widgets moderate comments

Warehouse: receive shipment notification

Finance: receive payment information confirm payment information process payment approve order



Features

This is similar to behaviors, except the behavior is what the actor does and the feature is what the application does.

A buyer needs to see three purple widgets on their homepage.

Possible features: featured widget box on homepage display three featured widgets on homepage featured widget box stands out with a highlight featured widget box is at the top of the main content area



For each of these features, I would estiamte the value to be medium or high and the complexity to be relatively low. These are low-hanging fruit which can be safely reserved for later in the project if need be.

A more difficult behavior might be for the warehouse actor. The warehouse needs to receive shipment notifications, which is a bit involved:

user order must be approved high value, high complexity

approved orders must be parsed into ASCII flat file format high value, medium complexity

flat file must be FTPd to warehouse automatically medium value, medium complexity

automatically FTP credentials are not in the repo high value, low complexity



The goal here is to start to communicate what the behavior means to the developer. Communication goes both ways, and this gives a framework for prioritizing development tasks as well as describing the tasks that must be performed.

Feature specification language: Gherkin

Feature specifications are the formal binding of the process. Starting with features like featured widget box on the homepage and user order must be approved , we write Scenarios and steps which explicitly define each feature.

By writing our feature specifications in Gherkin, we effectively bridge the gap between business language and programmer logic in a well-defined manner. This is accomplished through example.

More on Gherkin can be found in many places. An effective summary might be:

Feature a sentence describing the feature, and then three sentences explaining why In order to As I want to gain

Scenario A one-sentence use-case of the feature First-time site user buys 2 purple widgets

Steps: Given , When , Then , And , But These are conventions; all steps may be treated the same by your BDD framework Givens setup pre-conditions Whens perform actions Thens check for outcomes Ands continue (i.e. given… and…) Buts are for exclusion (then this but not this)

, , , , Background A set of steps that applies to a group of scenarios

Scenario Outline A template for generating scenarios based on example data

Examples tabular data used for populating the scenario outline templates



This might look like the following:

Feature: Multiple site support In order to generate traffic Admins should be able to Post to internal blogs Background: Given a global administrator named "Greg" And a blog named "Greg's anti-tax rants" And a customer named "Wilson" And a blog named "Expensive Therapy" owned by "Wilson" Scenario: Wilson posts to his own blog Given I am logged in as Wilson When I try to post to "Expensive Therapy" Then I should see "Your article was published." Scenario: Greg posts to a client's blog Given I am logged in as Greg When I try to post to "Expensive Therapy" Then I should see "Your article was published." Scenario Outline: Eating while blogging 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 |

Steps

We’re only going to talk in detail about steps. Properly written step definitions translate directly into automated end-to-end tests.

Given I am on the homepage When I click on ".featured .purple-widget[data-id='1'] .buy" Then I should see a ".confirmation-dialog" element And I should see a "button.confirm" element And I should see a "button.cancel" element

The words I have chosen match up against the Cucumber-Mink Step Dictionary – this saves us a lot of time.

Step definitions

Cucumber-mink step dictionary saves us from having to write the javascript which validates that UI elements are present. If you’ve never done testing before and that sounds tedious, rejoice! With over 350 unique steps, I only had to manually define maybe 20, and these were around database interaction and uncommon UI.

If you were to write your own step definition in Cucumber.js, it might look as follows:

this.Then('I should see "$title" as the page title', function (title, callback) { // the above string is converted to the following Regexp by Cucumber: // /^I should see "([^"]*)" as the page title$/ var pageTitle = this.browser.text('title'); if (title === pageTitle) { callback(); } else { callback(new Error("Expected to be on page with title " + title)); } });

Summary

Behavior Driven Development is a process that starts with a goal and ends with Gherkin. All features added to a project are tied to business goals through desired user behavior All features are formally specified The formal specifications become automated end-to-end test

Use BDD on your project to end up with a fully end-to-end tested deliverable where every feature adds value.

Good luck, best wishes, happy hacking :)