The importance of Behavior-Drive Development

Take this fun cartoon as an example. It perfectly shows how communication works in most projects. In the world of software development, it's all too common that a customer wants a swing but gets a seat and gets a roller coaster bill. This is where Behavior-Driven Development (BDD) comes in, a philosophy that not only accelerates software development but also improves communication and collaboration 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, at Lemon, we start by building a roadmap of all behaviors within the app. This ranges from logging in at the beginning to all actions the user wants 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, the Three Amigos. At Lemon, we involve the developer, customer and product architect in this meeting. There, we discuss the actions previously taken and turn them into workable use cases to create a shared understanding and determine acceptance criteria.

Let's take “login” from the previous step as an example. There are several ways in which a user can log in, and depending on what type of user logs in, the behavior may be different. For example, it may turn out that a user with an administrator role should be redirected to a different page after logging in. These use cases are translated into scenarios that include steps that a user must take to perform the action. These are bundled in a feature file. At Lemon, we use Gherkin to write down these scenarios, a language with a lot of support for testing in almost all programming languages.

The login example scenario might look something like this;

There is an art to writing these screenplays, for which it is LETTER-principle is used.

• BBusiness Language: Scenarios must be formulated with words that come directly from the business domain. This allows all team members, including those who are not tech savvy, to easily understand the scenarios. Avoiding jargon and technical terminology is essential to promote business team engagement.
• Real data: The function files must contain real possible data instead of 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 helps identify potential issues or edge cases that might otherwise be overlooked.
• IIntention revealing: Scenarios should reveal the intent of what the actors in the scenario are trying to achieve, rather than focusing on the mechanism of how they are going to achieve it. By focusing on the “what” instead of the “how”, scenarios can better illustrate the intended functionality and prevent 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 behavior of the application without being distracted by unnecessary details.‍
• Focused: Each scenario should focus on illustrating one specific rule or behavior of the application. This ensures a clear and structured approach, where each scenario corresponds one-on-one to a specific function 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 see BRIEF itself as a rule. Keep your scenarios as concise as possible.

Once all these scenarios have been created, we validate them again in a Three amigos meeting. This ensures that every stakeholder understands them and gives the opportunity to correct any errors and misconceptions.

3) Execute and fail

Once the feature file has been reviewed and reviewed, developers can start using it and start developing. The feature file is 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 that are in the Gherkin file.

At Lemon, we use test-driven development. Take our admin login example: if we were to implement the functionality first and then test it, there is a good chance that the test, especially one that checks the current page, would show consistent success. To avoid this problem, at Lemon, we first write Cucumber tests before implementing functionality. This approach helps to reduce the chance of misleading test results.

4) Write code to get through the step

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

5) Execute and succeed

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

‍

Stakeholder benefits:

BDD offers benefits for all stakeholders in a project. BDD provides a more streamlined development process with lLive documentation, fewer misunderstandings, and better collaboration between team members and stakeholders. In addition, stakeholders separately derive a number of benefits from BDD;

Product Architect/Functional Analyst:‍

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

Developer
Better understanding of expectations.
Shared understanding of requirements.
Early feedback.
Easily identify what's broken when developing new features.
BDD tests can serve as documentation, making onboarding easier.
Increased developmental efficiency.
Automated test cases.
BDD test cases: readable, verified, discussed.
Customer:
Can correct misunderstandings more easily.
Retains participation in 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 about a project that they can understand.
Can sell these benefits to potential customers.
The reports serve as easy-to-share examples of how it works.
In a nutshell, Behavioral Development offers a structured and collaborative approach to software development that not only improves the quality and efficiency of the development process, but also the communication and engagement of all stakeholders.

‍