The Importance of Behavior-Driven Development

Take this lovely cartoon as an example. It is a perfect representation of how communication goes in most projects. It is all too common in the world of software development that a customer wants a swing only to receive a chair and be billed a rollercoaster. This is where Behavior-Driven Development (BDD) comes in, a philosophy that not only accelerates software developement, but also improves communication and collaborations between teams and customers.

‍

The five steps of BDD and how Lemon implements it:

1) Describe Behavior

With BDD, everything starts with describing the desired behavior of the software. By default, we at Lemon start by building a roadmap of all behaviors within the app. This ranges from the login at the beginning to all the actions the user wishes to do within the app itself.

‍

2) Write Step Definitions

Before we do anything, we have a meeting with all the people involved in the project called the Three Amigos. Within Lemon, we include the developer, client and product architect in this meeting. There we discuss the previously created actions and change them into workable use cases to create a shared understanding and to determine the acceptance criteria.

Let's take "login" from the previous step as an example. There are multiple ways a user can log in, and depending on what kind of user logs in, the behavior might be different. For example, it might turn out that a user with an admin role needs to land on a different page after login. These use cases are translated into scenarios which contain steps that a user should take to perform the action. These are bundles inside a feature file. Within Lemon, we use Gherkin to write down these scenarios, a language with a lot of support for testing in almost all programming languages.

The scenario for the login example before might look something like this;

There is an art in writing these scenarios, for wich the BRIEF principle is used.

Business language: Scenarios should be formulated with words taken directly from the business domain. This allows all team members, including those who are ot technically savvy, to easily understand the scenarios. Avoiding jargon and technical terminology is essential to facilitate business team engagement.

Real data: The feature files should contain real possible data rather than random text such as lorum ipsum. This ensures that the scenarios are realistic and can be better understood by all stakeholders. Using real data also help identify potential problems or edge cases that might otherwise be overlooked.

Intention revealing: Scenarios should reveal the intention of what the actors in the scenario are trying to achieve, rather than focusing on the mechanics of how they will achieve it. By emphasizing the "what" rather than the "how", scenarios can better illustrate intended functionality and avoid misunderstandings.

Essential: Scenarios should focus on illustrating a single rule or functionality. Elements that do not directly contribute to this goal should be removed to maintain focus and keep scenarios clear and concise. The goal is to clarify the desired behaviors of the application without distraction by unnecessary details.

Focused: Each scenario should be focused on illustrating one specific rule or behavior of the application. This provides a clear and structured approach, with each scenario corresponding one-to-one to a specific feature or functionality of the application. This way, teams can focus on understanding and implementing one behavior at a time, optimizing development efforts.

And as a bonus, you can think of BRIEF itself as a rule. Keep your scenarios as concise as possible.

Once all these scenarios are created, we once again validate them in a three amigos meeting. This ensures that every stakeholder understands them and gives the opportunity to fix any mistakes and misconception that might have been made.

‍

3) Execute and Fail

Once the feature file has been discussed and reviewed, developers can proceed to work on it and begin development. The feature file will be translated into tests, where each step of a scenario represents a test.

In the previous step we used Gherkin as the language for the feature file. This allows us at Lemon to easily use Cucumber acts as a tool for linking tests to individual steps outlined in the Gherkin file.

At Lemon we use test-driven development. Consider our admin login example: if we were to implement functionality first and then test it, there's a high chance that the test, particularly one checking the current page, would consistently indicate success. To avoid this issue, at Lemon, we adopt a practice of writing Cucumber tests prior to implementing functionality. This approach helps reduce the likelihood of encountering misleading test results.

‍

4) Write code to pass the step

Now that the tests are written, we can write the code to make them succeed. For example ensure that the user can log in, and that admins end up on their own screen.

‍

5) Run and Pass

Finally, the test cases are run again and should now all pass, indicating that the software is functioning correctly according to specifications. Thanks to our use of Cucumber, we can export these results into a nice rapport.

‍

Benefits to Stakeholders:

BDD provides benefits to all stakeholders within a project. BDD provides a more streamlined development process with living documentation, reduced misunderstandings and improved collaboration between team members and stakeholders. Beyond that, stakeholders separately derive some benefits from BDD;

Product Architect / Functional Analyst:

• Maintains status of projects through living documentation.
• Has an overview of all functions.
• Improved communication with all stakeholders through the use of Ubiquitous language.
• Remains continuously involved through Three Amigos.
• More control over what automated tests are written for.
• Gets early validation of acceptance criteria.
• Reduces manual testing and provides faster feedback on software quality.

Developer:

• Better understanding of expectations.
• Shared understanding or requirements.
• Early feedback.
• Easily identify what breaks in new feature development.
• BDD testing can serve as documentation, allowing for easier onboarding.
• Increased development efficiency.
• Automated test cases.
• BDD test cases: readable, verified, discussed.

Customer:

• Can correct misunderstandings more easily.
• Retains participation within the project.
• Clearly defined functionality with faster validation => fewer errors and repair costs.
• Transparency in the development process through living documentation => has an overview of everything that happens.

Sales:

• Can indicate what has been done in a project.
• Has documentation on a project that they can understand.
• Can market these benefits to prospective clients.
• The rapports serve as easily shareable examples of how it works.

In a nutshell, Behavior-Driven Development provides a structured and collaborative approach to software development that not only improves the quality and efficiency of the development process, but also communication and involvement of all stakeholders.