Behavior-Driven Development

Behavior-Driven Development

Behavior Driven Development is an Agile software development 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."

By: Kelvin Kam and Alyson Gombos

Behavior Driven Development is an Agile software development 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 requirements.The next step is writing test cases in a natural language that non-programmers can read, specifying scenarios of system behavior. A scenario 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 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

    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 test automation tool for lean and agile teams. It supports Behavior Driven Development, specification by example and agile acceptance testing. 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 debugger 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
    • 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