What is Behavior Driven Development, and why is it valuable?

Behavior Driven Development (BDD) is the process of defining user/system behavior with concrete and testable logic that guides software coding and prevents software defects. BDD is an Agile methodology. The process involves writing the test scenarios and setting up the tests first, then coding the new software. Each software iteration is tested against the new test scenarios (for a new feature) and also tested against the full set of previous scenarios (for legacy features).  

Behavior Driven Development vs. Test Driven Development

Behavior Driven Development is an Agile methodology, and so is Test Driven Development (TDD). They both use pass/fail tests to eliminate software defects. Some sources claim that BDD emerged from TDD, and the two are closely related — that much is indisputable. 

TDD tests are written by an engineer or software developer, and the focus of those tests leans heavily toward criteria that can quickly be tested on the system backend or in a developer’s IDE.  BDD tests are usually written by a stakeholder, a tester, a UX designer, etc., but there’s still an engineer or software developer who sets up and runs the tests. BDD tests are highly effective for acceptance testing; the focus leans most heavily toward the front-end of an application and interactions between the user and the software.  

Behavior Driven Development is a collaborative process, and it requires conversation and exploration to make sure all possible scenarios are uncovered. At Pixo, we work with each stakeholder to:

1. understand your existing system or set of tools,
2. define the requirements and expectations for creating a replacement, and
3. locate inefficiencies and pain points with your current tools/systems/workflows/etc.

Where we typically start

We usually ask to see any existing documentation that would tell us more about how people interact with a current system or tool. All of those “how to” guides and checklists that get passed around and updated once in a blue moon. Even the sticky notes on the side of your monitor…  All of it could be a BDD goldmine. 

We start by getting familiar with existing training manuals or other internal guidelines; it’s a lot like onboarding a new co-worker. We get as familiar as possible with every pathway, workflow, pipeline, and edge case. The goal is more than understanding how an existing system operates — it’s understanding how the new version can be better than anything before it. 

What to expect

We listen to users, admins, product owners, and other stakeholders, and we ask a lot of questions about everyone’s goals, processes, and workflows. Together, we explore how everyone will need to interact with the software and what the software should do in response. 

Every unique narrative gets documented as its own test scenario. These are concrete, real-world examples that illustrate how the system should behave. We use those examples to ensure that new features will operate optimally for all scenarios, even the edge cases.

What are test scenarios and feature files?

BDD test scenarios are similar to user stories. But, while a user story can sometimes be too prose-heavy or hard to decipher, BDD test scenarios are concise. In fact, they are so concise that they can be fed into an automated system and parsed into a test-friendly format. 

At Pixo, our test scenarios are written as “.feature” files. These files are kept with the source code of the software. A system’s BDD test suite will include multiple “.feature” files, and each file will contain as many test scenarios as necessary to ensure the feature behaves accordingly.   

As systems grow larger, so does system complexity. Adding new features to a system can often affect legacy features in unexpected ways. In some cases, new features can change the behavior of a legacy feature or break it entirely. BDD tests are the key to long-term system stability, and they are the best failsafe against this problem.

A system’s set of BDD tests are most valuable when tests are written during the inception of the system, and its value only increases over time because the set of tests will continue to expand as the system’s functionality expands. When building a new iteration of the software, we don’t just run the most recent set of tests, we run the entire set of BDD tests. Yep — all of them! Running the full set of BDD test scenarios against each new iteration of the software ensures that all previous functionalities and system behaviors remain exactly as they were. And, that most recent set of tests ensures the features of the new iteration are also up to spec.  

Reincarnation anyone?

All software systems — regardless of how bleeding-cool the tech stack, will eventually become outdated. Perhaps the most impressive aspect of BDD is its potential for test criteria to outlive its original software system. BDD tests help define the workflows and processes that support your business infrastructure, and the test scenarios are a reusable record of the business logic that the software was built to serve. When the time comes to rebuild a newer (sleeker) system, and that core business logic still remains the same, the BDD test scenarios can serve as a blueprint for building it. 

Not to mention, even if the original software could somehow never go out-of-date, the team that maintains or iterates on it will most certainly change over time. A well-maintained test suite ensures that legacy knowledge stays with the source code, not with the source coder.