Writing tests with BDD

1. The four Ws of BDD

1.1. What ?

BDD (Behaviour-Driven Development) is a concept in which acceptance tests are written as examples that anyone on the team can understand. The process of writing those examples is a collaborative effort of the developers, testers, and the business owner (“los tres amigos”). They decide together if the thing they set out to be built is the right one, before starting implementing it. In doing so, a deliberate effort to develop a shared, ubiquitous language (used and understood by everyone involved in the project) for talking about the system is created.
BDD scenarios are built around the keywords: Given, When, Then.

1.2. Why?

There are numerous benefits for using BDD:

  • high quality communication -> Using a common language creates a better communication between the technical (developers/testers) and the non-technical (business owners) members of the team.
  • business needs directly tied to code -> Business needs are translated into scenarios and then into code.
  • thinking through solutions before implementing code -> Issues are spotted and handled before beginning to implement code.
  • requirements better understood and estimations more accurate -> Quality communication leads to the clarifying of requirements which are then broken into smaller pieces making them easier to estimate.
  • code is self-documenting -> The scenarios become a living documentation for the code.
  • writing testable code, and having an increased confidence in your code -> For most of the code written there are tests implemented.

1.3. When and where?

BDD is useful when you want to increase your chances of  “building the right thing”. The 3 main parties, Business Owner (BO), Developers (D) and Testers (T) are involved in outlining the product and its acceptance criteria before the software development process is started. It is essential that the BO is willing to spend time and resources when involved in scenario specification.

2. How to BDD

Before implementing a certain feature or even the whole project, the business owner has a discussion with the developers and testers in which the requirements of the product are defined in the form of scenarios with examples. Then, those scenarios are attached as resources -feature files- in the automation tool and will represent the automated acceptance tests.
Feature files are written in plain language that can be understood by people who don’t have a technical background. BDD specific tools are able to manage these files without the need to have them translated into a technical language.

To illustrate the use of BDD, here is an example from a WordPress demo project.

WordPress is a web software used to create blogs and websites. Its core software is built by hundreds of community volunteers. It has a Dashboard (used by author/moderator to manage content) and a content page for the website/blog.

For this project we used Cucumber, which is a tool to support BDD with plain text specifications. Cucumber is one of the most popular choices. The original Cucumber is written in Ruby, but it now also works with Java, .NET, Flex, and web apps written in other languages. As we wrote our tests in Java, we used the Cucumber JVM – a version designed for BDD with Java. Other frameworks used to implement BDD are JBehave (for Java) and RBehave (for Ruby).

In the case of our demo project, there were no BO and devs involved. We, the testers, built the scenarios and then implemented them. But this was only for demo purposes.
We started the project by choosing some functionalities to focus our testing on, thought about requirements and then created feature files for each of them. Feature files are interpreted by Cucumber.
In the image below you can see an example of a feature file from our project.

Feature File Example

3. Tools (Cucumber – the popular option, Selenium- web-app specific, Java (JUnit), Maven, IDE – Eclipse & IntelliJ)

Besides Cucumber, the tools we used for our demo project were:

  • Selenium WebDriver, since WordPress is web-based. We used it to automate actions in our browser. Selenium WebDriver uses the browser’s native support for automation to make direct calls to the browser.
  • JUnit – since our tests are written in Java we chose to use the JUnit as our testing framework. An additional reason is the fact that Cucumber already knows how to integrate with JUnit.
  • Maven – used as a build automation tool and to describe the dependencies within the project.
  • [IDE] Eclipse & IntelliJ- multiple languages interpreters and compilers.

4. Implementation

Using Maven we can declare dependencies for Cucumber, JUnit and Selenium and plugins in a Project Object Model (pom.xml).
We set up our project as a typical Java test project:

Java Test Project Configuration

In the src/test/resources folder there are the .feature files which have corresponding classes in the src/test/java/features file (for example, the scenarios in writeComments.feature file have the code implemented in the WriteComments.class). But this was our choice in order to follow the code better. Cucumber does not restrict you to a naming convention as to in what class the scenarios are implemented.

In order to run the tests we must specify the cucumber options. These can be specified in a java class or directly in the command line.
An example of specifying the cucumber options from the command line:
mvn test -Dcucumber.options=” –format html:target/cucumber-html-reports –format json:target/cucumber-html-reports/cucumber.json –format junit:target/junit-test-reports/Report.xml”

We can run all the implemented features, individual scenarios, or even a certain step from one scenario, which is a unit test.
Below is an example of a scenario written in a .feature file and implemented in a java class:

viewComments.feature

Scenario Example

ViewComments.java

scenario implemented in java class

In our project we chose to keep all the used objects (declaration and initialization) in a separate class. Thus, all the feature classes could use them at any given moment and if one of the elements change during development, we would only need to update one line of the scripts – this helps a lot during maintenance.

5. Other tools (Git, Jenkins – Amazon Jenkins, SourceTree, Bitbucket)

The demo project was implemented by a team of testers. We used Git as a SCM source code management tool and Bitbucket as a hosting service. Other useful tools were SourceTree and the Git plugin for Intellij IDEA, which eased our way with Git.

The tests run were published on Jenkins which offers an easier way to integrate changes to the project, and provides a visual representation of the test results. We also connected our Jenkins to a remote public server (http://jenkins.altom.com/) so that the test results could be accessed from outside our internal network.

6. Conclusions

Due to the fact that the application tested has already been published, we played the BO role and delivered our user expectations of a certain feature. For the developers’ input, we referred to the published work and tried to extract information from there.

As you see, this has not been a typical BDD project but it helped in understanding the concept and its way of implementation.

That’s it! We hope you enjoyed reading about our experience with BDD 🙂

Subscribe to our newsletter

And get our best articles in your inbox

 Back to top

Leave a Reply

Your email address will not be published. Required fields are marked *