BDD is a modern concept that is becoming increasingly popular. Behavior Driven Development is one of the agile methodologies used to carry out development work. Its aim is to facilitate communication and cooperation between technical and non-technical team members, and to allow business representatives to maintain control of the project. Is that how it works in practice? In the text, I explain what Behavior-Driven Development is, how it differs from TDD and what the most common errors associated with it are. What are BDD practices? Read on to find out!
- 1. What is Behavior-Driven Development (BDD)?
- 2. BDD process
- 3. Test-Driven Development (TDD) vs. Behavior-Driven Development (BDD)
- 4. Example of requirements in BDD
- 5. The advantages of BDD
- 6. The disadvantages of BDD
- 7. Developing software systems with BDD – common mistakes
- 8. Let’s read test code
- 9. Software development time
- 10. Behavior Driven Development BDD: yes or no?
- 11. When will BDD testing work?
- 12. FAQ
What is Behavior-Driven Development (BDD)?
BDD testing is an agile behavior-determined software engineering process that focuses on meeting specific requirements. In BDD, documentation and tests are written in natural language. Ideally, BDD should be an integral part of the entire software development cycle. The functionalities should be described in the Gherkin language used for this purpose at the stage of requirements collection and analysis, and then used (or developed) in the design and implementation phase.
BDD process
When starting the manual tests, the tester relies on existing documentation, which clearly shows the initial conditions, all the necessary actions and the expected results. Next, based on this, automatic tests are created in a natural language.
The tester is assigned to a task concerning manual tests or writing an automatic test. Thanks to the clear form, he or she knows what to do, and issues with interpreting the task should not arise. But does it always work this way? I’ll answer this question later in the article.
Read also: Software testing: do we really need more tests?
Test-Driven Development (TDD) vs. Behavior-Driven Development (BDD)
Behavior-Driven Development is often compared to the Test-Driven Development (TDD) approach. Test Driven Development is also an agile software testing process. It is based on repeating the cycle of Red – Green – Refactoring and software development is based on tests written for functionalities that do not yet exist. The main difference between BDD and TDD is that software development teams using BDD utilize language that is comprehensible to everyone – even non-technical team members – as shown below.
Elevate Your Application Development
Our tailored Application Development services meet your unique business needs. Consult with Marek Czachorowski, Head of Data and AI Solutions, for expert guidance.
Schedule a meetingExample of requirements in BDD
Here is a fragment of the business requirements, which are also the real (not pseudo-) code:
Scenario: User add article Given: User is logged in When: User add new article Then: Article should be displayed
The advantages of BDD
The above example instantly shows the advantages of BDD. Documentation that uses a natural language is available to everyone, including non-technical teams in the project, and facilitates the development of applications at various stages. Team members have a shared understanding and can discuss documentation in pre-implementation and in-progress meetings, and then use it in automatic tests and reports (if generated) to visualize the status of the application. Also, non-technical team members, e.g., business people, can have an insight into what business paths are covered by automated tests. Thanks to this, they can verify whether the application is developed in accordance with the assumed business purposes from the very beginning.
However, in fact, it may look quite different.
The disadvantages of BDD
Now let’s move from theory to practice. Sometimes the assumption regarding the use of BDD differs from its actual implementation in the project – for example, when the BDD approach is used only for tests. As a result, BDD is no longer a software development process, but becomes a form of writing automated tests. How can we avoid such situations? What are the most common mistakes while using Behavior-Driven Development?
Developing software systems with BDD – common mistakes
- Business does not provide ready-to-use scenarios in the form of “Given, When, Then”
The reasons are different: they need extra time (and also money) to do so, or the respective people are reluctant or insufficiently competent. Usually, the Product Owner provides the business requirements in the language that is most comprehensible to him, and translating them into Gherkin is put aside. In such a case, the tester cannot copy the text and use it directly in the code. This way the work which should have been done at a much earlier stage falls on the tester, who needs to rewrite the business requirements instead of focusing on testing.
- A test scenario is created after developing a functionality
As with TDD, BDD tests should be a leading element of the software development process. However, this cannot be achieved if the scenario is created afterward and not – according to best practices – before writing a given functionality. Non-simultaneous work of the tester and the developer is also a problem. If the scenario was not provided earlier, the tester creates it partly based on documentation and partly on the developer’s work. As a result, tests are refined only at the end, before closing the Sprint, and the testers try as they might to test the functionality and close all tasks.
- The business is not interested in the content of tests
I mentioned that the argument for the use of BDD is the possibility of team members without technical knowledge reading such tests. In practice, I have never had a situation in which a business representative would be interested in the content of tests. Business representatives are rather interested in reports and color charts. Typically, the Product Owner asks the team what the status of the application is, if the functionality is ready, or if there are any errors to be corrected.
The full content of the test reports is known only to testers, and only they monitor, maintain, and develop them. If people without technical knowledge were more willing to read the tests, communication in the project would indeed be easier. In addition, such people would gain knowledge on how to communicate the requirements in a more tester-friendly manner, which would expedite the start of the project.
Read also: All you need to know about Quality Assurance and Quality Control.
Let’s read test code
But let’s imagine that someone without knowledge of programming languages would like to keep their ear to the ground and check the content of the tests. Is the full form of BDD the only way to achieve this? Below is a fragment of code saved in Java using the Serenity BDD framework (but without using its capability to work with the Gherkin language):
@Test
public void itShouldBePossibleToAddNewArticle () {
// Given
loginPageSteps.signInUser(testUser);
navBarSectionSteps.clickNewPost();
// When
editorPageSteps.addArticle(defaultArticle);
// Then
articlePageSteps.articleShouldBeDisplayed(defaultArticle);
}
As you can see, based on these few lines of code, it is not necessary to have programming knowledge to understand that you need to log in, add an article, and check if it is visible. Below you will see the generated report. Note that methods such as “clickNewPost ()” are automatically processed into the text “Click new post”:
If a typical code is properly prepared, it should be easy to analyze, regardless of technical knowledge. There are also tools like Serenity BDD or Allure that help generate reports. Theoretically, if the library of steps is developed well, even a person without programming knowledge could add further tests. However, this is difficult to put into practice, as usually you also have to add new methods apart from the already existing ones. Usually, to some extent, you can use the existing implementation as a form of assistance, but this requires a knowledge of programming.
Software development time
I mentioned that it is important to apply the BDD approach only as a whole, at every stage. This is another relevant argument that, in my view, points to the disadvantage of using BDD in the tests only: time. BDD imposes another layer of abstraction in the created code, which, in turn, requires extra time to understand, create and maintain it. This means you need to include more people in the project, or testers, who deal with the maintenance of BDD instead of creating new tests and maintaining the existing ones on an ongoing basis, so that the tests are readable for people… who do not actually read them.
Behavior Driven Development BDD: yes or no?
BDD is a trendy, widely used catchphrase and now you can come across content praising this approach all over the Internet. However, the decision whether to use BDD (or any other approach) in the project should not be determined by the desire to follow the trend, but rather preceded by in-depth analysis. Problems may also occur if BDD is only partially applied.
Read also: What is mock testing?
When will BDD testing work?
BDD will fulfill its role if it is implemented properly in the overall software development process, meaning from the stage of collecting requirements. If we want to use it only for test automation, without conducting an in-depth analysis, BDD may not be a good solution for every project. Simply put, if the aim of the tests is to move the mouse and type in text, you can easily find other tools that will allow you to do it, saving a lot of time. This is my private opinion based on various experiences I have had during my testing career. However, I believe there are plenty of examples of the correct implementation of BDD, and I hope my article will also help to increase awareness of this matter.
FAQ
“Simply put, if the aim of the tests is to move the mouse and type in text, you can easily find other tools that will allow you to do it, saving a lot of time.”
Which tools, for example? I am just getting to know the world of automation and I was intrigued by your opinion. Most often I encounter writing scenarios in Gherkin’s syntax (Cucumber / JBehave) and then mapping steps and only implementing methods on the elements of the page – it is quite convenient – what alternatives do we have?
Answer:
Pure Selenium can be an example of such a tool. However, if you want to use a wrapper, I recommend Selenide – this tool is very popular within the JCommerce test team. For reports, Allure will be a good solution.
When it comes to the 3 steps that you have described, the first 2 steps can be merged. You write the script right away in Java.
Here is an example.
- Write tests by adding clear names
@Test
public void itShouldBePossibleToAddComment() {
}
2. AddGiven When Then
@Test
public void itShouldBePossibleToAddComment() {
//Given
//When
//Then
}
3. Write a scenario in Java
@Test
public void itShouldBePossibleToAddComment() {
//Given
articlePage.pageIsOpened();
//When
articlePage.addComment(comment);
//Then
articlePage.commentShouldBeDisplayed();
}
4. Implement the methods from step 3.
Such a code should also be understandable for a non-technical person. And if that is a problem, there is an @Step annotation in Allure. Now to the method:
commentShouldBeDisplayed();
You add @Step nnotation (“Comment should be visible”)
then the code will look like this:
Public class ArticlePage {
@Step(„Komentarz powinien być widoczny”)
public void commentShouldBeDisplayed() {
//implementacja metody
}
}
And in the Allure report, this step will be visible as “Comment should be visible”.
The sample report to get a better picture:
Useful links:
- https://demo.qameta.io/allure/#suites/195f684b9efefacfd69049419f325b4b/30e90f9ce75efea9/
- https://selenide.org/
Consult your project directly with a specialist
Book a meeting- 1. What is Behavior-Driven Development (BDD)?
- 2. BDD process
- 3. Test-Driven Development (TDD) vs. Behavior-Driven Development (BDD)
- 4. Example of requirements in BDD
- 5. The advantages of BDD
- 6. The disadvantages of BDD
- 7. Developing software systems with BDD – common mistakes
- 8. Let’s read test code
- 9. Software development time
- 10. Behavior Driven Development BDD: yes or no?
- 11. When will BDD testing work?
- 12. FAQ
Tomasz deals with test automation for web and mobile applications. He is a graduate of the Cracow University of Technology and the Jagiellonian University. Privately, a husband of a wonderful woman.