Beyond Behavior-Driven Development – BDD Gherkin tutorial for automated testing

Gherkin is a very useful language, part of the popular Cucumber tool. And it is not useful just for QA specialists. If you want to find more about its benefits, read the first part of the series – benefits of using Gherkin in Business Analysis. Read it also if you haven’t got to do much with Gherkin yet, because today I’m going to go much deeper into what Gherkin really is and isn’t about. 

Ready? Let’s go! 

Different shades of BDD

I’d like to begin with a story about one of many projects I’ve had the pleasure to work on. This project employed BDD framework Gherkin to the letter, but it had its ups and downs…

A (sad) world without BDD

It all seemed really great at the start. The development team I was a part of received a task concerning a large legacy system. We were given two parts of system documentation, a couple of hundred pages each. It was detailed, well-written and transparent. It was clear that it took lots of effort to create. However, as it is often the case, the more time we spent with it, the less perfect it seemed. It proved in part inconsistent. Besides, it lacked a description of the app’s behavior in cases when the user performs unusual actions.

Of course, it’s next to impossible to predict every single case scenario given. It wasn’t exactly a flaw of the documentation itself. The bigger problem was how much time it would take to update it with all the necessary information it lacked about a scenario given. The process was complex and required the participation of many people. As a result, the documentation was unreliable for us more often than not, despite all the effort that went into its production.

As a team, we wanted to be sure that our changes wouldn’t cause any regression. At that time, we lacked test coverage that would allow us to predict the behavior of the end-user – the end-to-end tests.

Another piece of the puzzle was the time of programmers. We had to implement the additional test coverage while making sure that it doesn’t put too much strain on the programmers. It’s all about the deadline. We brainstormed to come up with a plan that takes into consideration the interests of all stakeholders. What do I mean by that? Even more requirements… The business wanted to be able to look at the tests and system reports. The programmers needed time to implement all the new features. Manual testers lacked sufficient technical skills to do everything by themselves.

BDD to the rescue

How did we reconcile? We chose the BDD approach, which seemed to have fitted our needs just fine. 

The team implemented the infrastructure needed to run the tests. As testers, we focused on improving the test coverage of all possible cases. Developers assisted in creating the “Given, When, Then” domain steps based on the BDD Gherkin syntax. This Gherkin syntax solution presented some challenges as well.

Of course, there are no perfect solutions. Programmers were still forced to work on fundamentals, which were to bear fruit only later in the project. Non-technical team members had to learn how to create tests, which incorporated launching, debugging, using existing steps or describing the elements of the application. However, it was still faster than the alternative of having to teach someone how to code. The benefits of the solution and the time frame proposed proved acceptable to all stakeholders. We were on the right track.

I believe that we met most of the requirements. We did smoke testing after every change in the code and run all the tests every day at night. Business got a simple and easy-to-follow raport on all the manual and automated tests every month. Thanks to that process, we had more time for manual testing. Onboarding of new team members got easier with  up-to-date documentation. The team quickly learned how to create, analyze and debug E2E tests.

Beyond BDD – when is it not the best solution?

This project was just about perfect for BDD. Why? A couple reasons:

• long presence on the market,
• great long-term potential and extensive planning for the future,
• a large team that made the existence of good documentation all the more essential,
• an enthusiastic client that was able to see value in our work.

However, despite all the success, I still don’t think that using BDD as a default solution is a good idea. It introduces an additional abstraction layer, which requires implementation, maintenance and investment. We don’t want that in short-term projects.

I heard that BDD duplicates a lot of code. I don’t fully agree. It’s true that many steps use the same code. But that’s the unique nature of the approach – an important element here is a detailed decomposition of all the actions that take place during a test.

Based on my experience, debugging Gherkin syntax is somewhat more difficult because of the need to configure additional extensions in the IDE. But the biggest challenge is having to define steps that have a couple of parameters. It’s difficult to create a description that is clear, parameterized and short at the same time. It takes time. And there is no guarantee of success anyway. And there are also projects where there is virtually no interest in the Gherkin stories from the Business.

In these cases, a more technical approach might be warranted. Try this article from my colleague Marcin Basiakowski to learn more about optimizing automated tests.

Are there some other alternatives to this BDD Gherkin example? What’s a feature that this approach most lacks for the needs of the project. Is it the end of Gherkin?

Gherkin to power and speed up your automated tests

This approach deviates largely from BDD. Well, the truth is that it has little to do with BDD except for the goal of debugging the application and the use of the “Give, When, Then” syntax.

We’re going to show the approach by highlighting a couple of projects, which gave birth to Kakunin – TSH’s open-source E2E testing framework. Kakunin can be used to implement BDD, but it’s not its intended objective. More on that later.

The beginnings of Kakunin

We created Kakunin at TSH when we’re searching for a way to implement automation that could speed the testing process and make our applications more reliable. At first, there was only one person in charge of E2E testing automation. As the number of projects grew, it was increasingly insufficient.

The rest of the QA team was responsible largely for manual tests and documentation. They couldn’t help with automation without being properly introduced into the process first.

It was quite a challenge, but that’s exactly what we specialize in at TSH! At first, we created a simple internal framework called “Pascal, just test” (a reference to a popular cooking show called: “Pascal, just cook”). Our colleagues from TSH Adam Polak and Mariusz Richtscheid set off to create something really innovative.

What set it apart? It was generic, extendable and required no coding skills to use it to its fullest. As a matter of fact, there was no need to write even a single line of code to automate very complex forms. In addition to that, Kakunin supports most of the popular frontend frameworks by default, including React, Angular, Vue or ExtJS.

Let’s get to coding!

Enough with the background. It’s high time we did something coding. As we said, we aim for a generic approach – with the goal of being able to reuse the code in various projects.

That is pretty much the only place here where we get some JavaScript. One can also use the template and only add elements described by CSS or XPATH.

The example above uses only the steps implemented before. There was no need to write any additional code. And that’s just a small piece of all the features tested in dozens of projects.

Each step is generic – it can be used in any application. The only part that changes are the elements we reference.

The knowledge of CSS and XPATH will definitely come in handy. Beginners can also manage by copying the selector from the browser. Start typing to perform this action:

This approach saves tons of time at the beginning of the projects. For projects that take a couple of months rather than years, this is huge. It allows one to act swiftly and efficiently. You can find more information about the features and how to start using Kakunin.

Gherkin BDD tutorial for automated testing – summary

We should always adjust our tools and processes to the project requirements. The methods described above worked because they met this condition and they were implemented properly. Now that we have a lot of experience with Gherkin, we do believe that it can bring great value to the project and use BDD Gherkin best practices to our advantage in an efficient manner.

Kakunin is a fine example of how you can create value by escaping schemas and thinking out of the box. Using unconventional solutions can sometimes bring out very interesting results so we do recommend experimenting. Of course, not without a good level of reason to go along. 

Task description as told by Mikołaj in the previously mentioned article on automated tests is quite amazing. The clear description makes it easy to understand what the task should be. We can save time we would otherwise have to spend reading the docs. In addition to that, updating the docs itself becomes much easier with JIRA’s User Stories as opposed to huge works that require you to go through a couple levels of clearance to get anything done. You can easily observere when was something last updated, who last updated it, the reasoning and many other useful details about the project.

Using BDD Gherkin language is perfect when we have a great connection with the Business, the project is meant to be long-term and there is a good need for detailed and up-to-date documentation. But we do have to remember that it constitutes an additional layer that may generate big costs – too big for some projects. In such cases, BDD and Gherkin are not your only options. Kakunin or another similar framework may be a better choice. One way or the other, you need to choose a proper strategy for a scenario given to you. This is an important step in making your project a success.