Behaviour Driven Development using Behat
To bridge the gap between what is built and what is required several development methodologies have been created, one of which is Behaviour Driven Development (BDD).
Build what your customer wants..
How do you make sure, that the software you spend time building is something that your customer actually wants to use and is willing to pay for? In an attempt to bridge the gap between what is built and what is required, several development methodologies have been created, one of which is Behaviour Driven Development (BDD).
The original idea for BDD came from Dan North as a result of his frustrations with doing Test Driven Development (TDD) correctly. BDD helped to change the way that we approach software development, highlighting behaviours that start to guide the software development instead of the tests. However, tests should not be considered unimportant. It is really useful to have automated tests that run every time a change is made in the software, making sure the new features are well implemented and assuring also that the existing code has not been broken. BDD helps to remove the excessive focus that many TDD users wrongly give to testing, directing that same focus to the wanted/expected behaviour of the software.
When your development is Behavior-driven, you always start with the piece of functionality that’s most important to your user. You need to take off your 'Developer hat' and put the 'User hat' on. Once you’ve specified the user needs, you put the developer hat back on and implement your specification. BDD says you should elevate your mind to a level of behavioural abstraction above the code implementation. This change of emphasis and terminology leads people to write more useful specifications.
BDD tools and Gherkin
There are several tools that support BDD, including Cucumber in Ruby and Behat in PHP. This blog will focus more on the tool Behat.
Both of these tools offer a ‘natural-language’ way to specify behaviours in terms of “Given, When, Then” (GWT) sentence fragments. This language is called Gherkin. You create a plain-text file (called a “.feature” file) containing a set of scenario definitions written in Gherkin.
A typical Gherkin syntax would look like:
An example:Feature: User login As registered user I want to successfully login So that I can order books Scenario: Given a register user ”bob” exists When the user navigates to the “sign in “ page And the user signs in as “bob” Then the profile page of “bob” will be displayed.
Behat is a tool that makes BDD possible. Built using the framework for PHP 5.3.1 and 5.4, this tool was inspired by Ruby’s Cucumber.
Let’s look at a business scenario and a subsequent automated test script using Behat.
An admin user of an online store would like the ability to turn on/off the reviews written by customers for products that are sold through their website.
Firstly, we would have to install the Behat tool. Read a complete guide to installing Behat.
The following steps will describe the basic usage of Behat.
Create a new directory and set up Behat.$ mkdir test_project $ cd test_project $ behat -init
The behat –init will create the feature/ directory.
Define your Feature
It’s now time to define the business scenario. Behat always starts with a feature that you want to implement.#feature/productreview.feature Feature: Admin User can manage review visibility So that our customers are not influenced by a product with bad review history As an Admin user I want to disable reviews of those specific products
While this section is not important to Behat for executing the test, it is important to describe the feature and to be understood and readable by other people.
Next, add the following scenario to the end of the features/prodreview.feature file:
Each feature is defined by one or more “scenarios”, that explain how the feature should behave in different conditions.
Execute behat from test_project directory$ behat
The following code snippet is displayed on the screen. You can implement step definition for the undefined steps with these snippets in a features/bootstrap/FeatureContext.php file
Once the .php file has been created, run the Behat command again. If all is good, your output should look something like: #features/productreview.feature
Behat and Mink
Behat also offers a framework to test out web application using Mink. Mink is an open source acceptance test framework for web applications, written in PHP5.3.
It is a browser emulator abstraction layer. It hides emulator differences behind a single, consistent API. It works with drivers (Goutte, Zombie, Selenium, …) and can automate testing of the interface of your site.
What are the challenges and benefits to using BDD Behat for your project?
Developers write scenarios
- Scenarios written by developers look different to those written by the customer, but are customers willing to write and review the scenarios?
Is it easy to write?
- Yes for simple scenarios, but as you move to more complex scenarios that cannot be broken down to smaller chunks, it gets difficult to present it in Gherkin.
Time consuming refactoring
- Creating and maintaining automated acceptance tests is very costly compared to unit or integration tests.
Business value first
- BDD is user-centric and places value on what the business needs. Rather than getting caught in implementation details, it can help you focus on user needs and the expected behaviour. Any development, therefore, is aligned directly to your business.
- Between business and development teams. BDD aims to to create a common language between technical and non-technical teams. In short, BDD helps getting the right people to discuss the right things at the right time.
- It is important to show business value at every stage of the project. With a common communication medium being built, it is easier to break down each task based on business value.
In summary, whether it is right for your project or not, it is important to understand that BDD does help in implementing a software product that closely matches what the customer wants. Understanding clearly the customers needs from the start and testing external business behaviors that the entire team cares about, is a great way to ensure a quality project.