Smarter ideas worth writing about.

Behavior Driven Development - Part III

So far in this BDD blog series (BDD-1,  BDD-2) there has been no mention of any technical aspects of BDD concerning software automation. That was very deliberate, because BDD isn’t simply about a software tool that automates features, scenarios and related examples. BDD is more fundamental than that.  

Spoiler alert! - BDD is not about software testing, but, rather is about understanding behavior that is needed by software. The behavior is enriched with example based scenarios that allow for proving out the behavior is actually desired, wanted and needed. As Dan North1 began thinking about what has morphed into BDD, his purpose was to better explain to software developers how to conduct TDD2. What he found out was that behavior is quite distinct and different from a software test. With this important distinction in mind, this blog will go into some technical detail to understand BDD from the perspective of software automation including: 

  • Understanding how automation evolves from the feature, scenario and steps
  • Understanding the outputs of the automation and 
  • Understanding what a full-scale BDD implementation might look like

First a word about tools.  There is a rich variety of BBD software tools available that support popular frameworks and languages like Ruby, Java, .Net and Scala.  Each will have their own particular approach and of course advantages/disadvantages.  We don’t endorse any particular framework, that will be for you to decide.  In this blog, Cucumber for Java will be used to assist in understanding3.  

Now let’s see how automation works under the hood.  Let’s start here by repurposing the feature, scenario and steps from blog 2:


Provide frequent flyers with points based on flight mileage 


Earning standard points from an economy flight 
Given the flying distance between Sydney and Melbourne is 878 km 
And I am a standard Frequent Flyer member 
When I fly from Sydney to Melbourne 
Then I should earn 439 points 


What happens from an automation point of view?  What is the next activity to do with them? Is code written auto-magically and the project prospers?  Unfortunately, no. Neither Cucumber, nor any other BDD software writes production level code. That is left to the software developer. Rather, Cucumber will infer from the steps and make recommendations to the inputs and methods necessary to prove that the behavior is of value.

Cucumber uses regular expressions in inferring information from the step and in parameterizing the methods suggested.  Let’s look at the output Cucumber generates for the first step4, ‘Given the flying distance between “Sydney” and “Melbourne” is 878 km’.

@Given("^the flying distance between \"([^\"]*)\" and \"([^\"]*)\" is (\\d+) km$")
public void theFlyingDistanceBetweenAndIsKm(String arg1, String arg2, int arg3)
throws Throwable {
    // Write code here that turns the phrase above into concrete actions
    throw new PendingException();

Cucumber parsed the step and found 3 inputs.  Two of the inputs are strings and represent an origin and a destination of a flight (“Sydney” to “Melbourne”).  One input is an integer and represents the distance flown for the flight (878 km).

The words and unusual symbols following the @Given is the regular expression that Cucumber constructed that will pick out an origin, destination and fly distance from any similar step.  The 5 lines following the @Given expression are java code.  Cucumber places the 3 inputs found as parameters in a method named “theFlyingDistanceBetweenAndIsKm”.  That is a long method name but it indicates what behavior is of interest – the flying distance in kilometers between an origin and a destination.

What value does Cucumber provide at this point?  Dan North and other early adopters of BDD began to recognize that this is where code is structurally being understood from an outside in5 perspective.  As a software developer works on the code that will satisfy the inputs and methods that Cucumber recommended, the outcome is that only code necessary to prove out the behavior is written.  By concentrating on the behavior, the right code will be developed.

What’s next?  Following the completion of the first few behaviors, what is usually seen is more collaboration.  There is renewed discussion on what was missed, what isn’t needed, what additional scenarios are needed and what examples will assist in proving out the next generation of behavioral ideas for the software under construction.

We could stop right there and call that an implementation of BDD, but there are opportunities to go farther.  As a team works on coding more and more behaviors, they will need to also utilize practices that will ensure the software is being built correctly.  This may involve using test driven design, unit testing and refactoring.  

BDD has the capability to help here too by automating some of the testing and, as a by-product, providing some living documentation too because the code is so intuitive.

Where you go and how far you go with BDD will be up to you, but if you are looking for a new approach to help build bridges of understanding and arriving at software that behaves exactly as you want, this approach might very well be worth your while.

Authored by members of Cardinal's Agile Advisory Services, this post was written by Juan Flores, with contributions from Dave Wanner.
Realize that running Cucumber on this scenario will result in additional outputs.  They are not being show to reduce complexity.


About The Author

Business Analyst

Juan is a Business Analyst and senior consultant in Cardinal's Cincinnati office. He has spent over 17 years working in a variety of positions in the IT industry. Juan developed a passion for business analysis while working on a project transitioning from Waterfall to Agile and has been an Agile advocate ever since.