Effective Behavior Driven Development

It’s tempting to think of software development as a purely technical task—writing code to instruct a machine. In reality, software is the product of an ongoing socio-technical conversation among users, business stakeholders, and the delivery team. That conversation evolves over time, and the challenge is to capture it in a form that is precise, testable, and useful as a guide for building the system. This is the central goal of Behavior-Driven Development, or BDD.

BDD originated in the mid-2000s as a refinement of Test-Driven Development (TDD), created to make technical practices more accessible and closely aligned with business needs. Today, it is supported by a mature ecosystem of tools and years of hard-earned lessons from practitioners. From the initial discovery of requirements to the use of automated tests that ensure applications adapt gracefully to changing needs, BDD offers a collaborative, sustainable way to bridge the gap between intent and implementation.

Why is software delivery so hard?

The purpose of most software development is to deliver solutions to business problems. Despite well over 50 years industry experience, organizations still regularly experience significant challenges specifying, delivering and maintaining the software systems on which they rely.

You might be the victim of these challenges if you have struggled to find answers for some of the following questions:

• What does the customer actually need?
• How should we capture these needs in an unambiguous way?
• How do we make sure that these are understood by everyone involved in specification and delivery?
• How can we demonstrate that the functionality of what we deliver meets the customer’s needs and is adequately reliable?
• How can we ensure that the software will be able to adapt over time?

These questions span the entire software development process, from requirement analysis to maintainability, but in many cases the underlying issues are rooted in the following three key problems.

• Incomplete requirements – the requirements do not properly convey the information about the problem to be solved and the expected behavior of the solution to the team.
• Unreliable documentation – the maintenance of the system is hampered by the absence of documentation that reliably links the stakeholder needs to the functionality that the team delivers.
• Slow feedback – delay, unnecessary rework, or context-switching is required because of the lack of fast, reliable, meaningful feedback about system behavior.

An overview of BDD

Behavior Driven Development (BDD) is an agile approach to software development that closes the gap between business people and technical people. BDD emphasizes the collaboration needed to create and maintain linkage between requirements, documentation, tests and the system being developed. It is made up of three practices, shown in Figure 1, which illustrates the order that the BDD practices should be applied to iteratively ‘drive out’ each small increment of functionality in your application.

Figure 1

1. User stories are lightweight descriptions of a piece of functionality that will be of value to some user of the system. They are not requirements but are created in response to an understanding of the needs of the stakeholders.
2. Discovery is a structured, collaborative activity that uses examples to discover the detailed requirements of a user story. This practice helps uncover the ambiguities and misunderstandings that traditionally derail software projects.
3. Formulation is a creative process that turns the examples produced during discovery into business-readable scenarios. The subsequent review of the scenarios delivers the confidence that the team really has understood what the stakeholders are asking for.
4. Automation is where code is written that turns the scenarios into tests. Not only do the tests guide the implementation of the system, but they also transform the scenarios into living documentation. Every time the system is built, the tests give us feedback that the scenarios still accurately describe its behavior.
5. Working software is our ultimate result that BDD contributes to. There are many activities that take place after each scenario is automated, before the functionality described by the scenario can be delivered to users. These activities are not directly related to BDD.

User stories

User stories are a widely used agile concept. Each story initially captures an element of application functionality that might be valuable to the customer but defers detailed requirements gathering until the story has been prioritized for development.

Discovery

During discovery, the team participates in requirement workshops at which they create examples to explore and illustrate the expected behavior of the story. Focusing on examples makes the intention of the acceptance criteria and business rules clear – each should be illustrated by one or more examples. This is important because acceptance criteria and business rules are often subject to misunderstandings.

Formulation

The examples generated during discovery are the bridge between the requirements and the software. For this bridge to be useful for both business and technical people, the examples must be captured in a form that is accessible and meaningful to both. Formulation is the creative process that turns each example produced during discovery into a business-readable scenario that is understandable by all stakeholders, yet also precise enough to specify the software that needs to be written.

Automation

Once an example has been formulated as a scenario, it can be read by automation tools that understand the format produced during formulation. The team can now write automation code that these tools will call in response to each line in the scenario.

The team starts by writing any new automation code needed by the scenario they are currently working on. When they run the new scenario, it should initially fail (red) – because the implementation code that it specifies has not been written yet. Then they iteratively implement the application code (possibly using TDD) until the scenario finally passes (green). After cleaning up the codebase (refactoring), they move on to the next scenario. See Figure 2.

The BDD cycle is the outer loop – write a failing scenario, get the scenario to pass, then refactor. We enter the inner, TDD cycle to implement the code needed to move from a failing scenario to a passing scenario.

Figure 2

Automated scenarios also address many of the issues around unreliable documentation. Since the automation will be run during every build, the team will be notified whenever the system does not behave in the way a scenario expects it to. These failures have several possible causes:

• The functionality has not been implemented yet: implement the functionality.
• There is a defect in the code: fix the defect.
• The specification is incorrect or out of date: correct the scenario.

In this way, automated scenarios preserve a direct connection between the specification and the system implementation. This type of documentation is called Living Documentation.

Testing

BDD itself does not define how testing should be performed. Instead, it provides a set of practical guidelines that facilitate the agile testing process. The basic concept of agile testing is to move the responsibilities of testing from finding and reporting application issues to ensuring that these issues are never added to the codebase in the first place. When following a BDD approach, the responsibility for code quality is shouldered by the whole delivery team, not just dedicated testers.

Bridge

The examples uncovered during discovery are an executable connection between the behavior required by the stakeholders and the system implemented by the delivery team for the lifetime of the product:

• They provide the stakeholders with confidence that the team has implemented their requirements in a verifiable way.
• They provide the delivery team with confidence that they have correctly understood the stakeholders’ requirements.
• They provide the organization with confidence that side effects and regressions will be prevented as the system evolves.
• They provide the organization with confidence that there is reliable, persistent documentation of how the system behaves, ensuring its ongoing maintainability as the business and team changes over time.

BDD helps to maintain this connection and so acts as a bridge between the stakeholders and the delivery team, between the organization and the product, and between the past and the future.

Conclusion

BDD is a collection of practices that, on their own, seem mostly sensible and beneficial. Each can be described quite succinctly and don’t appear to be particularly demanding. However simple they sound, adopting them requires change, and no change is easy.

When done well, in whole or part, BDD practices have delivered improved outcomes for thousands of organizations globally. However, the collaborative and technical practices that make up BDD are dependent on the organization’s willingness to change not just what work is done, but how the work is done.

BDD is not a free lunch. Discovery will not succeed unless the product owner is truly available to collaborate with the team. Formulation will not succeed unless the business stakeholders are truly available to review the scenarios. Automation will not succeed unless the delivery team is truly willing to value all aspects of code quality. BDD is simple but not easy – you will have to work for your lunch.

BDD is not a silver bullet. There are many problems in product design and delivery. BDD focuses on aspects of software development that range from business requirements through to delivery and operations, but there are many aspects that fall outside the scope of BDD practices. There are problems that BDD cannot solve – you will have to decide if the problems BDD helps solve are the problems you most need to solve.

All change is hard, but change is possible and often necessary. We have tried to emphasize that BDD adoption is challenging, not to put you off, but to give you realistic expectations. The outcomes of successful BDD adoption – less waste, fewer defects, reduced rework, faster feedback, living documentation among them – are worth working towards. We have written a book, Effective Behavior Driven Development, to help you to adopt BDD practices.

This article is taken from Chapter 1 of the book Effective Behavior Driven Development by Gáspár Nagy and Seb Rose, published by Manning and available from https://www.manning.com/books/effective-behavior-driven-development

Gáspár Nagy is the creator of SpecFlow & Reqnroll, brings over 20 years of experience as a coach, trainer, and test automation expert. He currently leads SpecSync, aiding teams in test traceability with Azure DevOps and Jira.

Seb Rose has been a consultant, coach, designer, analyst and developer for over 40 years. Lead author of The Cucumber for Java Book (Pragmatic Programmers), and contributing author to 97 Things Every Programmer Should Know (O’Reilly).