Behavior-Driven Development: way beyond a testing principle

Picture this: 5 people talking about the same subject in different languages. What are the chances of misunderstanding? As you can imagine: a lot. Well, this is a common scenario in software development teams up to some point. One of the most common reasons that lead to failure when building a product is the lack of well defined goals and requirements amongst developers and stakeholders. This can be caused by a wide variety of reasons. But it is safe to agree that most of them are due to lack of communication.

Why mention people speaking different languages? Because every single collaborator involved in a project has their own perspective. The gap might get even bigger when talking about different areas of expertise, such as frontend engineers, testers, backend engineers, data analysts, you name it. This can be the equivalent to speaking different languages when it comes to project outcome. As a product owner or business analyst you have to digest the information in a way everyone understands.

BDD to the rescue!

BDD stands for Behaviour Driven Development. Originally conceived in 2003 by Dan North, it is known to be an Agile approach to software development and is emergent in this industry. It aims to do exactly what the title suggests: lead your development driven by behaviour. What does it mean? Behaviour can be described as a feature. A benefit that your product delivers to whomever uses it. BDD was created and designed to give value to stakeholders as its main focus.

And how do we achieve all of this? There are some key concepts defined by the BDD approach that address these matters. Let me talk about them.

Ubiquitous language

A term from Domain-Driven Design for a language shared by developers and business people to reach a common understanding of the terminology in a domain. Remember those 5 characters speaking different languages? Now they all speak the same. This means extending business terminologies all the way down from meetings with stakeholders to your code base. Yes, including database tables and class names too. Domain concepts, the same ones understood and used (or agreed) by users and domains experts should be used throughout the entire project stack. Let’s say that during a banking software development the concept of amortization has been introduced and the project designer calls the referred screen or menu link “Payment in installments”. Ubiquitous language is not being put into practice in this case.

Using examples

While explaining theory to someone we tend to use practical examples for better clarity, especially in cases of misunderstanding. The human cognition works better this way. So why not apply it to software development? Why not avoid misunderstandings? Planning and developing through examples is one of the key concepts of BDD. Giving real case scenarios of what you should expect from the product makes sense to everyone.

But how? One powerful and well known approach is the use of the Given-When-Then scenarios. Combined with the use of ubiquitous language it describes features with scenarios breaking them down into small stories consisting of 3 phases:

• Given: An initial state or condition. Usually describes the context before your feature is triggered.
• When: An action taken. The behaviour being described.
• Then: The output of this behaviour. The expected outcome given the initial state and after the triggered behaviour.

Speaking of which, it couldn’t be a better place for an example:

Feature: Money transfer

  - Scenario A: Transfer an amount of money lower than my balance
    - Given: I have 500 brazilian reais in my account
             And Rafael has 700 brazilian reais in his account
    - When: I transfer 200 brazilian reais from my account to Rafael's account
    - Then: I should have 300 brazilian reais in my account
            And Rafael should have 900 brazilian reais in his account.

  - Scenario B: Transfer an amount of money bigger than my balance
    - Given: I have 100 brazilian reais in my account
             And Rafael has 700 brazilian reais in his account
    - When: I transfer 200 brazilian reais from my account to Rafael's account
    - Then: I should have 100 brazilian reais in my account
            And Rafael should have 700 brazilian reais in his account.

Here we are describing money transfer. We have detailed the scenarios and if you have noticed we have predicted a case where the behaviour was not concretized.

We have also taken care of making everyone in the project understand what exactly the term account means. Considering that you will find more complex terms eventually, this needs practicing.

Impact Mapping

It’s all about getting to know what really matters. Impact Mapping sits outside of the box when talking about BDD. It is something used far beyond software development just like this excellent example. But as mentioned by Stead and Kudryashov, it is a strategy worth pointing out in a BDD approach, since it foments agile mindset when in use. There are various approaches to this method and it has a very high refine rate from the community. I would need an entire article for this subject, but let’s keep it short.

In software development it is common to see attempts of achieving as many features as possible when building a product. This can be an expensive flaw. Impact mapping consists of the following steps for product development effectiveness:

• Knowing your business goals.
• Knowing your actors that will be impacted by these goals.
• Knowing the impact itself. In what way the actors will be impacted? What will change?
• What can be done to support the designed impacts? The deliverable.

This will help your team narrow down the most important features and impacts and what can be done to deliver them. It will reduce waste and help prioritise what is most important. It helps everyone understand what is the business goal and prevent over waste before getting to it, since you get a deep look into complexity vs result.

Somebody said something about testing

What about tests? Once you have all of this pinned down, you know what to expect. The word should in testing frameworks is all about expectation and responsibility definition. But the key point here is that developers can work in a more collaborative manner, since the focus is the final result. Having a top down approach of testing guarantees the behaviour without forcing technical details to any of your developers. They can decide that in another level. Behaviour and value stays untouched. Are you a fan of unit testing? Stick to the top down approach: have the view of the bigger picture and write your unit tests separately.

But where is the automation behind all of this? After all, we are talking about software development. Dan North himself developed the first automated BDD testing framework in Java: JBehave. And, after that, came RSpec and Cucumber. With some research you can easily find others.

The best part is that these frameworks have practical functionalities for your project documenting. Although well written and specified behaviours are living documentation for developers, they can automatically generate end (non-technical) user documentation, the one read by stakeholders and non technical collaborators. This can save you a lot of time by integrating documentation with code.

Summing up

You now have everyone on the same level of understanding speaking the same language expecting the same results. All of these processes will demand many iterations involving everyone following a meaningful agile approach. These iterations consequently lead to a discovery process showing you possible flaws in advanced, since you have features put side to side in an atomic view. You can change your plans leaving the other features in peace (You have it all tested!). Again, following an agile methodology. You have also mapped and convinced stakeholders of the most important and impacting features. Which will definitely give a sense of effectiveness by the end of the project and keep developers focused on what really matters. Your stakeholders are happy up to this point. They see it all happening with clarity. Developers are happy. They don’t have the “requirements weren’t explained” issue that frustrates many. And they have a living documentation to stick to and to use for testing business values and guaranteeing the expected final results. It goes beyond testing.

I won’t end this post with that old cliché “It is not the silver bullet”, because BDD is not a bullet. It is the weapon! You choose the bullets. You adapt it according to your project needs. I gave an overview according to my knowledge of BDD, but you can dive into a sea of information that can give you many other options of use with BDD.