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 ALP™ gives you the benefits of BDD without learning a new language.
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:
- Carefully define the test such that it meets the requirements.
- Check that the current code actually causes the test to fail. If not it means your test isn’t defined well-enough.
- Write code to pass the test. This code can be as messy as needed.
- 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.
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 Adaptive Language Processing engine (ALP™). This allows you to write tests as a series of steps in plain English. The ALP engine then uses Natural Language Processing (NLP) to generate a Functionize test script. Like Gherkin, ALP uses certain keywords, but because of its NLP 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”.
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.