White Paper

Behavior-Driven Development Kelvin Kam and Alyson Gombos

Behavior Driven Development is an Agile technique focused on improving a key factor in the successful development of any software product: Communication. It is a technique devised by Dan North as a response to the issues he encountered whilst teaching Test Driven Development. Eric Evans describes it this way in his book Domain Driven Design: "A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design... Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand."

He goes on to describe the concept of modeling a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase. BDD seeks collaboration amongst the delivery team and business participants in a software project. On the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North gave the following definition of BDD: "BDD is a second- generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters."

It is a framework based on three Core Principles:

1. It’s All Behavior: Business and Technology should refer to the same system in the same way 2. Whereas The Business Value: Any system should have an identified, verifiable value to the business 3. Enough Is Enough: Up-front analysis; design and planning all have a diminishing return

Behavior Driven Development centers on obtaining a clear understanding of desired software behavior through discussion with stakeholders. From this initial discussion between the stakeholder or users and the business analyst comes a list of features of the system to be developed, features also known as "User Stories" in our Agile environment. They describe the behavior from the perspective of those interested in the product.

The format is:

As a [X], I want [Y], so that [Z]

Where X is the person (or role) who will benefit , Y is some feature , and Z is the benefit or value of the feature. Its strength is that it forces you to identify the value of delivering a story when you first define it. This can make it easier to descope some of the more esoteric .

The next step is writing test cases in a natural language that non- can read, specifying scenarios of system behavior. A describes the feature acceptance criteria. We call scenarios “acceptance tests;” they express what the software needs to do in order for the stakeholder to find it acceptable. So, everyone on the team, including stakeholders, writes these tests collaboratively, because they not only decide the system behavior, but they

White Paper learn how to describe that behavior in a common language that everyone understands. If the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t. So a template can be created to capture a story’s acceptance criteria.

The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them.

The next step is to automate these scenarios as examples, taking the following form:

Given – some initial context (the givens)

When an event occurs,

Then ensure some outcomes.

Acceptance tests written in this style become more than just tests: they are executable specifications and living documentation. When the software system is continuously validated against a set of executable specifications, the team ensures that the system will do what the specifications say. Or, to put it differently, the specifications will continue to describe what the system does.

They have the following benefits:

 Living documentation replaces all the artifacts that teams need for delivering the right product.  We can continue defining specifications as the system grows up, in an incremental way.  They are cheap to write.

To illustrate, a classic ATM can be used as an example:

Title: Customer wants to withdraw cash.

As a customer, I want to withdraw cash from an ATM so that I don’t have to wait in line at the bank

There are many scenarios that we can consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, but let’s use the given-when-then template for an example.

Scenario 1: Account is in credit Given the account is in credit

And the card is valid

And the dispenser contains cash

When the customer requests cash

White Paper

Then ensure the account is debited

And ensure cash is dispensed

And ensure card is returned

Scenario 2: Account is overdrawn past the overdraft limit Given the account is overdrawn

And the card is valid

When the customer requests cash

Then ensure a rejection message is displayed

And ensure cash is not dispensed

And ensure the card is returned

Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.

Tools Cucumber is a functional tool for lean and agile teams. It supports Behavior Driven Development, specification by example and agile . Cucumber is a Ruby tool that offers a natural-language way to specify behaviors in terms of "Given, When, Then" (GWT) sentence fragments. This language is called Gherkin. The syntax is extremely flexible: Cucumber only cares about the Gherkin keywords “Given,” “When,” “Then,” “And” (plus a few others); everything else is simply matched against your regular expressions. Any tokens captured by capture groups in your regexes are passed to your step definition blocks as parameters.

What makes Cucumber different from other testing tools? It is designed specifically to ensure the acceptance tests can be easily read—and written—by anyone on the team, to automate functional validation and functional regression checks for future changes. It assists the team in the creation of the executable specifications and living documentation. The easy readability of Cucumber tests helps you to explore and understand the business stakeholder’s requirements and, at the same time, to communicate to the delivery team the expected behavior of the features through scenarios.

Specflow is an open-source .NET tool that lets you write specifications using 100%-Cucumber-compatible Gherkin syntax, and has a number of advantages.

 It integrates with Visual Studio, which means you get File->New templates for creating new feature files and step definitions  It gives complete VS support, so you can set breakpoints on Given/When/Then lines in your .feature files and step through their execution  You can implement your step definitions in any .NET language

White Paper

 When you compile a project containing SpecFlow feature files, the output is a NUnit test assembly, so you can use your favorite NUnit-compatible test runner or existing CI infrastructure to run the specifications with no additional configuration.

Watin is an automation library that makes it possible to automate the testing in web applications, using any .NET language. So, with Watin, you can design your step definitions to implement the code that will drive the execution of the steps. It works with Internet Explorer 6, 7, 8, 9 and it supports HTML dialogs (modal and modeless). Watin enables easy HTML object recognition across multiple attributes in the elements.

References

 http://behaviour-driven.org/  http://en.wikipedia.org/wiki/Behavior_Driven_Development  http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business  http://cukes.info/  http://specflow.org  http://watin.org/

Back to the top