With this article, I'll walk through the behaviour-driven development methodology.

Let's jump straight in with an example of a behavioural test for a cash machine.

The first thing to notice is that the test is written in plain English.

The second thing to notice is the test is made of three different sections:

• Given : it's the arrangement of context state — the starting state
• When : it's the event, a trigger or when a user does something
• Then : it's the outcome with the expected results

Once scenarios are ready, the development team can begin their work. Each of the tests will be running — and in the absence of any code — they would fail. The developers start writing code. As more code is written the tests will begin to turn from red to green. When they are all green, the job is done.

What is BDD ?

Behavioural tests can be written for a system at any time: before, during or after development.

It can be very difficult to write unit tests for an existing system, but writing behavioural tests for an existing system presents no special difficulty.

The case where the tests are written first is termed behaviour-driven Development. The plain English nature of context, event and outcomes format that the business people can focus on describing the behaviours that matter to the customer.

When we think about BDD, we think about automated testing, or acceptance automated testing. We can come up with Cucumber, JBehave or some other frameworks. However, doing only acceptance automated testing does not mean BDD. The same idea goes for the case where Behavioural tests are written during or after development. They aren't be considered as BDD. There are aspects of BDD that incorporates automated acceptance testing, but BDD is not just about that. There are two parts that are missing: the collaboration and the common language.

BDD is an approach to establish collaboration between the product owner, testers and developers and why not stakeholders. It's a way to get to find and drive the value in the product we are trying to deliver, rather than having a siloed approach — the traditional way of developing software.

The last piece is the common language. When people are collaborating together, discussion about what matters, and the value of product, they need to use the same language to ensure they understand each other. The common language is about having the same vocabulary, business oriented.

Let's see what are the differences between the traditional way and the BDD way of delivery values to the business.

Software development process

In the Software development process, we have several players getting into the scene. In the case of waterfall flow, we can distinguish different roles: the customer, end users, business analysts, architects, developers and testers. And in an agile scheme we have these roles: stakeholder, production owner, scrum master, developers and testers. In both schemes, we usually have business analysts writing requirements (BRD), followed by some other business analysts on the development side writing solution requirements, then quality assurance manager writing a test plan, and finally testers are requested to execute tests.

Either a team is working an Agile or a Waterfall way, they still may be — or are — using the traditional software development process. And it's pretty hard to getting away from it because people are just used to it.

Working with that approach meaning that the respective people would do things in a sequential order:

1. for instance the business people would write down requirements in a document — typically called a BRD.
2. Then a Quality Assurance (QA) manager would prepare a test plan to organise the work for testers,
3. while the software architect is defining or adapting the existing architecture of the software and eventually produces a design document
4. From the BRD and design document, developers put their hands in code to fulfil the requirements by translate them to machine code — without understand exactly what they are about. They also have to make sure the technical documents are up to date.
5. And before the new features are being delivered, a bunch of tests — manual tests and hopefully automated tests — are run to ensure the quality is met. These tests are prepared and executed by testers. And testers typically translate requirements into test cases — again without having a clear understanding of the feature or product as a whole.
6. Once tests are all executed, they produce the test reports. If everything goes fine, the QA manager will give a GO for release.

Oh by the way, the quality gate of the release being shipped is not yet in place, they may want a DevOps engineer to put in place quality gate to show some metrics. With those metrics, they can decide to go live or not.

Here, testers and QA are translating from requirements to test cases, while developers translate them into machine code — in a one-way directive and in a straightforward way, without having a clear understanding. And they are all siloed and they are not talking very much to each other. And from time to time, they way ask questions to the BA or PO to get more details in order to have the functionality completed. And it happens that the finished product is not really delivering the value stakeholders are expecting.

We see there are a lot of things to take into account when developing software, and still it does not guarantee that the software would meet the expected quality.

What if they explore the BDD approach. What if BDD is providing a simpler way to bring up the quality of the software — as expected — in a more focus manner and more efficiently? So then, they have to understand — or better adopt — the BDD approach.

Nowadays, BDD is on the wall of fame — in the agile space, in the testing space as well as in the development space. It's making a big buzz, not exploring BDD or not trying it is not an option.

The BDD approach

The BDD approach is based on three major steps : discover, formulate and automate. The first on is quite important as it will drive all the work that follow.

During that first step, we may go through a tres amigos workshop, or an Example Mapping workshop, to reach a common understanding at multiple levels and so we can surface uncertainty to deliver software that matters. The stakeholder and product owner are not just telling about something to be done. They are talking about the business needs. So instead of giving directives on what to do, they start a collaborating phase and discuss about what they need, with developers and testers. What is important here is all about starting a discussion between the stakeholder/production owner and developers and testers to bring up the value that the business wants, by asking questions and providing examples that translate business needs. Here we would use a common language, and start using a vocabulary that everyone agree on.

Once everything is clear, we can write down everything, using the agreed vocabulary, then we will have a resulting dictionary which we can refer to during the entire software life cycle. And we would formulate the shared understanding into scenarios, using Gherkin format (Given, When, Then).

At last, we will use the scenarios as input to automate tests. In this article we will see an example with Cucumber implementation to automate scenarios.

Tres Amigos

The tres amigos concept relies on three perspectives - or roles:

• Business

The business perspective could be represented by a Stakeholder, Product Owner or a Business Analyst or both. They are to raise to the surface problems we are trying to solve.

• Development

The development perspective could be represented by developers, a technical Leader or Architects. They will help to build a solution to solve that problem.

• Testing

Testers, QA engineers, or sometimes developers will brings in their expertises in testing the product to make sure the quality is met. This workshop would bring to them another angle to tackle functional testing. And they would prevent from things that could possibly happen in an unhappy path?

Example Mapping

This discussion session, called an Example Mapping, is based on the tres amigos concept. People holding different perspectives should collaborate to discuss all the details, to define what to do and agree on how to do it correctly. The end result of such a collaboration results in a clearer description of the work leading to a shared understanding for the team.

A product owner chooses a story and writes the business rules. For each rule, he identifies the data to be used and the expected results. Data should cover all business cases, and the way to achieve that is using examples. From these examples, we can write down scenarios (given, when, then), in an order. They are then used for tests automation in that same order. If there is anything that is not clear enough, regarding the rules or the data, the three parties would ask questions and get answers to make sure they get out of the workshop with concrete and usable scenarios for User Stories. Those scenarios are in fact the acceptance criteria for the user story.

Writing scenarios BRIEFE-ly

From the examples out of the example mapping workshop, we would likely write down many scenarios. Depending on the complexity of the feature or user story, we may end up with several scenarios. However, there are some best practices when it comes to formulate them. The BRIEFE principle may be of help.

• Business vocabulary : use the agreed vocabulary among the tres amigos. That means anyone can understand. Avoid using terms that others can't understand.
• Real data — concret : use real data when explaining something, they serve as examples to represent the idea we want to tell.
• Intention : A sample must have only reason to exist. Name it with intention.
• Essential : A sample must help to understand the behaviour described in the scenario. If it does not, it's useless.
• Focus : There is only one interaction within a scenario.
• Empathy : Samples describe what the user is trying to do, rather than what he does. This helps to understand and maintain. Describe the behaviour rather than prescribing actions. This aims to build empathy for a better user experience.

Benefits

Perhaps the greatest strength of behavioural tests is that they describe in a very direct way the set of the behaviours of what the user can expect from the system. The list behaviours taken together from a "contract" of the complete behaviours that the system is expected to exhibit. If all the Behavioural Tests pass then the contract has been upheld. If any of the tests fail, the contract will be broken.

There is another benefit here that may not be immediately obvious. As a developer, we have a tendency to write too much code or code that does too much or code that includes some degree of supposed "future proofing." BDD is helping to keep focus on getting the behaviour test to pass. Nothing less — and nothing more.

Drawbacks

If all of this sounds too good to be true, it comes with some drawbacks:

• Behaviour tests tend to be a bit slower to run than unit tests
• When they fail, they only indicate that something went wrong, but may give little or no indication of the root cause

The Pitfalls

• One thing to avoid, because it is usually misunderstood, is to limiting three amigo discussions to only three people. The three perspectives are about roles, not about people. If there are other stakeholders who are relevant to a particular increment of work, include them in the discussion.
• Also avoid expanding the three amigos discussions to the team. The intent of this practice is to include each necessary perspective with as small a group as possible. The smaller it is, the more efficient it is.

BDD in Agile way

In Agile methodology, the Software Development Life Cycle is still present but with smaller scale, bringing notion of iterations and sprints. Beside, the Agile methodology also bring in new phases to the software development process, splitting in these five phases :

• Inception: Think of the what we want to achieve in terms of product — or product increment
• Story mapping: This is a workshop where we define the steps to work on delivery the values
• Refinement: Here we get into more details for each work items and define how solve the problem — in other words how we are going to implement the solution
• Sprint Planning: Once we have refined work items — user stories or tasks, we are going to commit on delivery values
• Development: Now it's time to put our hands dirty to produce the values

This is the common workflow of build software in an Agile way. If we dive into more details in the refinement phase — and we can see that as a process because it is cyclic from sprint to sprint — there are so many similarities to the two firsts steps of BDD along the 3 amigos concept.

Refinement

A Refinement — was called grooming - aims to refine items of the product backlog, thus get into details for each of them. There are many things to consider when doing refinements:

1. Timebox as part of Agile
2. Having a scope with focus on one or a few items
3. Implicate several roles (product owner, testers and developers), they should discuss together
4. Align people on a common understanding of each work items, thus an agreement of what has been defined
5. Refine each item by adding details and/or sub-tasks, by defining what is to be accomplished, and what is the value out of it, as much explicit as possible.
6. Reduce or maybe clear off uncertainties. Here we should not focus on the solution, but on the problem. But if there is any doubt on how to implement the item, write it down in the item.
7. Estimate the complexity of each item
8. Having acceptance criteria defined — as part of Definition of Ready

BDD stepped into the Refinement Process

Then if we look at the above list of best practices things in the refinement — above, we can see that a few are matched to what we have in the BDD discover and formulate steps, which are as followed:

• 3 amigos (product owner, testers and developers)

— > matching bullet 3 : Implicate several roles (product owner, testers and developers), they should discuss together.

• Discuss for covering uncertainties

— > matching bullet 7 : Estimate the complexity of each item.

• Reach a shared understanding

— > matching bullet 4 : Align people on a common understanding of each work items, thus an agreement of what has been defined.

• Define a common language
• Having scenarios using examples with gherkin syntax
• Having acceptance criteria defined

— > matching bullet 8: Having acceptance criteria defined — as part of Definition of Ready.

BDD Automation Step

Adding up the automation step, where we drive the development of each work item by using the scenarios written in acceptance criteria, we are optimising our work on delivering focused and expected values.

So we have these things as a bonus by the way :

• having automated tests (unit and functional)
• having a living documentation
• favouring design driven and test driven development
• good code coverage

Automation with Cucumber and Spring

Step 1: Bootstrap a spring application with cucumber

You may refer to this repository bootstrap-spring-cucumber-java to bootstrap an application.

Step 2: Add a scenario

Create a withdrawal feature file under ./features:

Step 3: Generate the glue code

Simply run mvn clean verify`:

This will generate the glue code in the console:

Step 4: Add the glue code to the Step Definitions class

Copy/paste the glue code to the step definitions in the following class.

./src/test/java/cucumber/stepdefs/StepdefsBankAccountWithdrawal.java :

Step 5: Implement every step definition (failing scenario)

Step 6: Implement business code (passing scenario)

Here we can loop with TDD to cover happy unit test cases, unhappy unit test cases, and corner cases, even extreme test cases. Here we still need to keep focus on the scenario. All corner and extreme test cases must be surrounding that specific scenario. Once all unit tests passed, we can make the scenario pass. Then we can continue with another scenario.

Living Documentation

Once the business code is implemented to satisfy the business requirement, simply run this command mvn clean verify` again to execute again the tests.

Now a report is generated under ./target/cucumber/cucumber-html-reports/overview-features.html. Open it with a browser to see the results and you should see this:

That is what we call a living documentation. The approach "Specification by examples" aims to describe business requirement using concrete examples. And it comes with a living documentation as a result, examples of behaviour becomes the documentation per se. They are also promoted into automated tests. Whenever a test fails, it indicates that the documentation is no longer in sync with the code so it must be fixed as soon as possible. If the documentation has to evolve because the business changes then the code will evolves too, as they are glued together.

Wrap up

BDD emphasises on the three steps of first, discover the business requirements by the 3 amigos in a workshop discussing together using a common language (dictionary of business vocabulary). The discussion are based on examples to ease the understanding. Then they formulate their understanding by writing down those examples in scenarios. Once scenarios are written, we can use a tool or framework, such as Cucumber, Behat, SpecFlow, JBehave or some other, to convert them into automated tests.

Testers can use these scenarios as a basis of their tests, and the developers can use them as a basis of their automated tests. And once these automated tests driven through, they are run and passing, then reports are generated against the scenarios.

By having all of these reports automatically generated and scenarios living side by side to the code, and along with all the history of change, we are closer to 100% sure they are up to date all the time. So we also have the traceability, because any change to scenarios is historised the same way as the code change.

Write Medium in Markdown? Try Markdium!