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:
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:
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.
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
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.
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.
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.
