Misbehaviour with BDD

A general misconseption, which I also shared until Mauro Talevi’s presentation last week at Skills Matter, is the idea that Behaviour Driven Development (BDD) should only be used in completely agile environments. Mauro explained in his presentation that this is not necessarily true and he shared his experiences of applying BDD for a global investment bank for the past year.

BDD brings some concepts from Domain Driven Design (DDD) into Test Driven Development (TDD), such as having a Ubiquitous Language for bridging the divide between Business and IT. (It seems like the recent increase of “Driver candidates” for our design and development caused people outside the industry hate IT even more, as I heard one person say “DBB or BBD whatever…” rolling her eyes, before the event) . One of the main advantages of BDD is that, tests describe the behaviour. Additionally, acceptance tests can be executed. Mauro said that he sees BDD as synonimous to integration testing because it allows you to see the system from above the boundaries and from the eyes of the stakeholder by speaking the language of the business.

My first introduction to the concept of BDD was when I attended to Chris Parsons’ (CEO of Eden Development) BDD Workshop, which was held 1 day before the Rails Underground Conference ’09. In that worksop we experimented with Cucumber for applying BDD techniques. This time, I had a chance to see examples from a Java based BDD framework, named JBehave, and Mauro Talevi is also an active contributer to the core development of JBehave.

The example used during the presentation was a stock price monitoring system. The following test can be used to test the expected behaviour about when to notify a broker about the stock prices:

Given a threshold of 15.0
When a stock is traded at 15.5
Then trader should be alerted
When a stock is traded at 5.0
Then trader should not be alerted

Here, we use a grammar like: Given -> context, When -> event, Then -> outcome, And -> (repeat previous structure)

JBehave maps BDD steps to methods. For example, in a similar situation to the example above, our tests should be like:

// Given a threshold of x
@Given(“a threshold of $threshold”)
public void aThreshold(double threshold){

//When a stock is traded at y
@When(“a stock is traded at $price”)
public void aStockIsTraded(double price){

//Then a trader should be alerted
@Then(“trader should $beOrNot alerted”)
public void traderAlerted(String beOrNot){

JBehave allows you to have custom parameters by implementing the ParameterConverter Interface.

DateConverter implements ParameterConverter {
  public Object convertValue(String value, Type type) {
    // DateFormat injected in DateConverter
    return dateFormat.parse(value);

The command line interface supports both Maven and Ant. They support any IDE that supports unit testing with JUnit. They also provide a BDD layer on any web testing API. He gave the following example for Selenium:

public class YourSteps extends SeleniumSteps {
  @Then(“there are $some messages”)
  public void someMessages(int some) {
    int count = selenium.getXPathCount(“//foo/bar”);
    assertEquals(some, count);
  // more steps

We don’t have to show this peace of code to the stakeholder. The only sentence he/she needs to see should be: “Then there are x messages”. This way the functionality is much better communicated to the business.

Next, Mauro introduced the Scenario Web Runner, which provides a web interface for running generic scenarios. The fully functional example webapp that was shown during the presentation can be found here.

Case Study

The project that Mauro was involved in started in September 2008 at a global investment bank. It was a messaging and transaction management architecture . Initially the focus was on back-end, but later web front-ent development was also added. They used Scrum. The communication went well because they used scenarios to communicate behaviour. Since the behaviour was visible, this allowed the team to gain confidence.

When it comes to disadvantages, the fact that formats like CSV and XML do not refactor very well caused some problems in maintaining large data sets. For example, it may not always be easy to determine if an xml representation represents input or output data. Additionally, these formats are not very appropriate to show data to stakeholders.

A chart that shows the increase in the number of scenarios per 2 week sprints. (Image taken from the presentation slides)

Mauro also stated that, it is hard to determine the optimum way of verification. For example, capturing an expected output in a file may be more complete, but embedding into the scenario text may be more readable and refactorable. Another decision might be to capture the whole object, or only a field in that object. He also mentioned that it is hard to keep the development process behaviour driven all the time because the business side may not be available all the time or there might be misunderstandings caused by lack of enough business analysis. In these situations, the issues that were not covered due to lack of business analysis or another reason, can be catched at the next sprint, after discussing with the business side.

If there are too many repititions of similar steps in the scenario, the scenario data should be refactored and it should be reviewed to fit into a more suitable form for the business side. Other than repetition of scenario steps, this also applies to repetition of entire scenarios. Another leeson learned was that, pairing among developers, testers and business analyists lowers the risk of misunderstanding.

This presentation showed that BDD can play a key role in building trust between development and business sides and producing software that matters to the business.


Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>