BDD and Cucumber

#Behaviour Driven Development

Behaviour Driven Development, or BDD, is a software development process that takes test driven development and mixes it with ideas from domain driven design.

At its core, BDD is all about uniting business users and developers. Through the use of an ubiquitous language, common domain problems and user stories describe how the system should behave. When business and technical talk about the same things in the same manner, this serves to increase understanding and productivity across a team.

In BDD, business cases and system features are expressed in structured, yet natural language.

It expands on domain driven design in that it uses tools to execute the system specifications, making acceptance tests behave more or less like tests in TDD.

BDD also dictates that the development process follows a pattern similar to TDD:

• Write the (failing) specification fist
• Implement the specified feature
• Verify that the feature works according to the spesification

The key is that everyone involved in the problem domain should be able to understand and discuss the specification!

###Methodology - this is not the workshop you where looking for If you came to this workshop looking for BDD in practice, you will be disappointed. This workshop will rather look at one of the numerous tools available for implementing the executable specification bit of BDD: Cucumber.

There will probably be some talk about BDD during the workshop though.

For a little more on BDD, take a look at the wikipedia article.

#Cucumber Cucumber is an implementation of testingtools useful when practicing BDD. However, you do not have to follow strict DD-practices to get value from a test-tool like Cucumber. Even small shops of developers can benefit from more formal, yet easier-to-read acceptance tests to document their system.

Cucumber interprets files written in Gherkin, a domain specific language for expressing semi-structured specifications by example. The files typically looks like this:

Feature: Hosting a workshop at Booster

Scenario: The perils of the workshop host
Given I am a workshop host
And there is yet tasks to be made
When the day of the workshop arrives
Then I will be stressed

Features will typically be backed by executable code, which builds up state for the specification, triggers some action then validates the results.