There’s more to BDD than just Specflow

How can we bridge the gap between business and development? How do we make sure that features being developed are according to the business requirements, right from the beginning? Today, test automation offers several solutions to make tests more efficient and sustainable. This is where we can say hello to Behavior-Driven Development (BDD)! 

We are in 2023 and the options for software testing have never been more abundant. But the availability of a vast array of tools can also make it overwhelming to find the best solution for your specific needs. The good news is that now it’s much easier to access these tools. Although there is no doubt that a higher set of tests (distributed across the right test levels) help us to ensure the quality, reliability, and functionality of a software system, software testing is still often considered a necessary evil. “Time-consuming”, “extra work after programming” - these are only a few of many such terms that are constantly associated with testing.

In fact, when launching new digital projects, the frequent disconnect between business professionals and engineers often results in wasting lots of time and resources. This also explains the continuous efforts in test automation towards counteracting these problems. The goal is not only to become faster and more efficient and also to improve communication, which is always an effective way to prevent most bottlenecks to project progress.

In creating software with real business value, business professionals and engineers should understand each other's capabilities and what the business needs from software. So how do we do this? Can BDD be the solution that ticks all the boxes?

What is BDD?

Behavior Driven Development (BDD) is an agile approach to software delivery. This software development process has gained a lot of momentum over the last decade and is driven by the behavior of an application. It is also known as an extension of the Test Driven Development (TDD) approach.

BDD emerged as an alternative to test automation, which was too technical for non-technical team members and stakeholders to understand. A new layer was introduced to add easily-understandable English while the code would be at the backend.

BDD consists of three practices that must be addressed in the following order:

1. Discovery: The first practice is discovery, which is a structured, collaborative activity that uses concrete examples to uncover the ambiguities and misunderstandings that traditionally derail software projects.
2. Formulation: The second practice is formulation. This is a creative process that turns the concrete examples produced during discovery into business-readable scenarios. The subsequent review of the scenarios delivers the confidence that the team has really understood the key business requirements.
3. Automation: The third, and final practice is automation, which is where the code is written to turn the scenarios into tests. This is where we begin discussions about the tooling and frameworks we can use to start our automation.

While improved test automation is one of the most significant outcomes of following a BDD approach, it is a downstream outcome. Unless you adopt the practices strictly in the given order (discovery, formulation, automation), you will not be able to derive the benefits expected out of them.

Conversely, you will achieve significant improvements in your software development activities just by practicing discovery on its own. Add formulation and you’ll get the extra benefits that come from growing a truly ubiquitous language through an active review and feedback process.

What exactly is Specflow ?

Specflow is a tool that is often used in BDD. A testing framework for .NET projects, BDD allows users to define and specify their expected software behavior in a logical, readable way, with its ordinary language parser (Gherkin) and then generates executable tests from these scenarios. Besides providing a testing framework, SpecFlow also includes several other features that can support BDD, such as the ability to generate documentation from test scenarios and integration with test runners like NUnit and MSTest.Figure 1 SpecFlow, Cucumber or similar tools are not testing tools, they were designed to facilitate the process of BDD. (this can be used as the alt text too) Source: https://www.functionize.com/blog/what-is-gherkin-how-do-you-write-gherkin-tests

Do I need Specflow or Cucumber to get started with BDD?

Absolutely not!

While SpecFlow is a valuable tool for implementing BDD, it's important to remember that it is not BDD itself. BDD is a mindset and approach to software development that can be supported by a variety of tools and techniques.
While tools like SpecFlow can be useful in supporting the behavior-driven development (BDD) process, they are not strictly necessary. BDD focuses on the behavior of an application from the perspective of its users and can be implemented by using a variety of tools and techniques.

One way to practice BDD without using a specific tool is to define the acceptance criteria and use them to guide the development process. Defined by business analysts, acceptance criteria outline the specific behaviors that the application should exhibit. By using acceptance criteria to guide development, teams can ensure that the final product meets the defined requirements and aligns with business goals.

Another way to practice BDD is to focus on collaboration and continuous integration. By working closely with all stakeholders and continuously integrating and testing changes, teams can identify and address issues early on, leading to a higher-quality final product.

Since BDD also helps preserve the quality and maintainability of the software, the implementation cost of new features is kept on the lower side. This is in contrast to many other projects where, as the codebase grows, the cost of adding (or modifying) a feature increases exponentially. If allowed to deteriorate in this way, your project will finally reach a point where it would no longer be possible to add new features in a cost-efficient way and people will start talking about a “rewrite”.

BDD: Benefits Definitely Due

BDD offers a unique advantage by guaranteeing that the end-product aligns with the needs and expectations of users. It includes business analysts and non-technical stakeholders pretty early in the development cycle, thus ensuring that the primary focus stays on the desired behavior and outcomes of the application. This fosters better communication among stakeholders and helps to prevent misunderstandings caused by language barriers, unclear requirements, ambiguous domain terms, and different interpretations. By addressing these issues, BDD reduces the risk of defects resulting from miscommunication and improves the chances of delivering a high-quality product that meets the customer's needs.

BDD also supports the concept of "Shift left," which means moving testing earlier in the development process. By continuously integrating and testing changes, teams can identify and address issues early on, rather than waiting until later in the development process. This can help to reduce the risk of costly rework and can lead to a higher-quality final product.

Figure 2 Source: https://devopedia.org/shift-left

Specflow vs BDD

One typical mistake is to see BDD as a tool. BDD is not a tool you can download, it is a set of practices. It is an approach just like Agile – so while Specflow is an automation tool that supports BDD, it is not the same as BDD. BDD is not test automation – it’s collaborative requirements analysis combined with test-driven development (TDD) which, despite that name, isn’t testing either!

The common problem is that almost no one uses BDD as a set of practices. No practices are implemented to remove the built-up waste and technical debt. Instead, tools such as SpecFlow are used to write automated tests and then it is claimed that they are “doing BDD”.

BDD is primarily about collaboration and domain discovery; any “BDD tool” can be only useful in supporting this process. You have to start by investing in collaborative discussions and by creating a shared vocabulary. Just going after automation (using SpecFlow or Cucumber) does not work.

The same happens with BDD frameworks, like SpecFlow. 

 Figure 3 The Blind Men and the Elephant: A Metaphor to Illuminate the Role of Researchers and Reviewers in Social Science - Scientific Figure on ResearchGate. Available from: https://www.researchgate.net/figure/The-Blind-Men-and-the-Elephant_fig1_290127733 

When done right, BDD ensures no more miscommunication, minimal rework, and no more of those “I wish I had known that earlier!” moments. It’s true that Specflow and Behavior Driven Development are closely related for most people. But at its core, Specflow is just a test runner that aims to combine the gherkin notation with glue code to validate a system under development. Technically, it can be used within teams that do not actually practice BDD. And vice versa, you can practice BDD without any need for a framework.

How to get started with BDD ?

I don’t believe in buzzwords, but if you intend to evaluate the BDD approach objectively, it is important to do it at full throttle during the evaluation period. You might feel uncomfortable or skeptical when you actually start doing BDD (just like how it will be with any other new approach). That is absolutely fine, but don’t let your apprehensions hamper the evaluation. Once you have decided to evaluate how BDD could work for your team, give yourself enough time to get comfortable.

So in the future, when your team decides to start using BDD, try to focus on what you want to achieve with it and how it will probably change the dynamic of your way of working in a team, and your communication with one another. How you can automate it is just the tip of your BDD-iceberg journey.

If we aren’t actually communicating more to promote a better understanding of the product, then it doesn’t make sense to add an automation tool that creates more complexity, hinders your ability to parallelize well, and overall just makes our life as automation engineers even harder.

Get in touch with us to know more about how you can optimize your BDD journey with Nagarro.