Behavior Driven Development without the pain

BDD – what it is and how to use it

Putting your business needs first

Behavior Driven Development (BDD) is a development methodology that places emphasis on meeting the business needs of the software. In this blog we explore what BDD is, why you might choose to adopt it and how to define features in BDD. At the end we show how Functionize’s NLP Engine gives you the benefits of BDD without learning a new language.

Overview

Behavior-Driven Development, or BDD, evolved from Test Driven Development (TDD). Test-driven Development was first formalized by Kent Beck in 2003. The aim of TDD is to create clean, simple code that satisfies the requirements with no or minimal code bloat. As the name suggests, it achieves this by coding to pass tests, rather than to meet requirements directly. BDD takes this a step further, providing a domain specific language and a set of tools. These tools provide a framework in which to specify your features in terms of unit and acceptance tests. By forcing you to be exact with your language you have to create unambiguous definitions. This enables you to create tests that are much more closely aligned with the needs of the business.

What is BDD

And how to use it

TDD breaks software down into components defined by tests. BDD uses a domain specific language to generate tests that are closely aligned to the business and rigorously defined.

Test-driven development provides a rigorous framework for developing software. The software is broken down into simple components and for each component you create a test. When creating tests for TDD, you go through a set of steps:

1. Carefully define the test such that it meets the requirements.
2. Check that the current code actually causes the test to fail. If not it means your test isn’t defined well-enough.
3. Write code to pass the test. This code can be as messy as needed.
4. Improve/refactor the code, checking that the improved code still passes the test.

The trouble is, TDD is careful to be ambiguous about technical details. As a result, the code produced will only be as good as the definition of the test allows. By contrast, BDD has strict rules on how to write and define features. These are designed to ensure the tests align properly with the needs of the business. It does this using a domain-specific language. Several of these exist, but probably the most popular is Gherkin, which is used by the Cucumber BDD software.

Cucumber and Gherkin

Cucumber was originally released 10 years ago as a tool for Ruby developers to help them with requirements testing. They were one of the early proponents of the BDD methodology. Their domain specific language for BDD is called Gherkin. Gherkin is a language designed to allow product teams to define requirements for new features. In Gherkin, every feature is defined in a .feature file and follows a very precise syntax. Each line in the file starts with one of the Gherkin keywords and defines one aspect of the feature. The aim is to create unambiguous definitions for each feature which can then be tested precisely. Gherkin is intended to be human-readable, but, as with formats such as XML, it isn’t designed to be an easy read!

A simple example

Let’s use one of our favorite examples to illustrate how to create a feature in Gherkin. Imagine you have an eCommerce website. You want to create a buy now button that should add the specified number of products to the shopping cart. A simple .feature definition for this might look like:

Notice how steps are linked together using the and and but keywords. Of course, any piece of software consists of multiple features and features may be more complex than the one in the example above. The skill with effective use of BDD is to create features with the correct scope. 

Having defined your features, BDD uses its tools to create the method that will implement the test for each feature. The language used for these methods will depend on the language supported by the tool. Cucumber was designed for Ruby, but you can also use Gherkin to generate Java, JavaScript or Python methods. Hooks then allow you to define pre- and post-conditions relating the test (e.g. the state of a database).

Don’t get yourself in a pickle…

As you may have noticed from the examples given, Gherkin may be human-readable, but the strict format can make it time-consuming and hard to define features. This is because it is using a dumb syntax-based approach to convert your .feature file into the methods used to run the test. In other words, you have to do a lot of the hard work by making sure you are writing something it can understand.

Here at Functionize, we don’t deny the utility of Behavior Driven Development. Clearly, making sure your features align with your business needs is valuable. Equally valuable is “shift-left” – thinking about how to test your features before they are developed. However, our view is that Gherkin is simply too inflexible and hard to learn. Our solution is our recently-released NLP Engine. This allows you to create tests by simply writing in plain English. The NLP engine then uses Natural Language Processing to generate a Functionize test script. Like Gherkin, NLP engine uses certain keywords, but because of its capability, these can be used in a much looser manner. For instance, you can have a step “Verify that the Buy Now button is visible at the bottom of the page”.

Conclusions

BDD is an interesting way to think about software development. It takes the best features of TDD and ensures that the resulting software is delivering what the business needs. However, BDD’s reliance on overly-precise domain-specific languages and special tools limit its utility. With ALP, Functionize offers you a way to get the benefits of BDD without the pain of learning a new language.