In today’s article, I’m going to show you how to build a test automation framework using the Playwright-BDD library.

Recently, I’ve been focusing mainly on using AI in our work, but today I want to shift gears and talk about integrating Playwright with BDD.

BDD is a popular approach to creating automated tests. When implemented properly, it can act as a bridge between business and technical teams.

What is BDD?

BDD (Behavior-Driven Development) is a methodology that requires defining requirements and tests in a structured way.

In practice, it’s often used primarily for test automation, where scenarios are defined in a specific format using a pseudo-language called Gherkin.

Due to its semantics, Gherkin enforces a clear and consistent way of writing tests.

Requirements are written in Feature files, which describe scenarios related to specific parts of the application.

Within a Feature, we use keywords such as:

• Given
• When
• Then

Each step defines a specific action.

Additionally, other commonly used keywords include:

• And
• Background

We can also pass data into steps using mechanisms such as data tables or scenario outlines.

Why is BDD useful? Maybe it’s only an unnecessary additional abstraction layer?

BDD has both supporters and opponents. There are many discussions about this methodology online. From my perspective, BDD is useful for complex systems where we have system analysts and the application domain is specialized and complex. In such cases, Gherkin (and BDD) can serve as a bridge for communication between different roles. I took part in a few projects where BDD was implemented well, and it made test automation easier to understand and helped demonstrate its real value.

Of course, one might argue that there is no need to use BDD if the code is already self-explanatory and provides sufficient logging and reporting. If someone wants to introduce BDD, but it ends up being just an additional layer of abstraction used only by the test automation team while other people don’t use it — then it’s a bad idea. In that case, it can only add difficulties for the team and increase the time spent on developing automated tests. It can be useful when the entire team wants to use it together, and the domain is complex. Also, steps can be useful for manual testers or analytics, and they can help in creating them (obviously, after some introduction), and because of that, they can help in creating more test cases.

Rules that help using BDD:

1. A test scenario should be written as business requirements instead of a bunch of actions:

Feature:Shopping cart checkout

Scenario: Customer applies a valid discount code at checkout

Given a customer has a "Wireless Headphones" priced at $120.00 in their cart

When the customer applies the discount code "SAVE20"

Then the cart total should be $96.00

 And the discount "20% off" should be displayed

1. Given step describes the existing situation, so in this case,   a particular product is in the cart with a defined price.
2. Next step is “When” step, where we describe the use of a discount code for a specific price.
3. The “Then” and “And” steps are assertions. The “Then” step describes how much should be in the cart, and “And” steps are very useful because we can use them after each kind of step, like “Given”, “When”, “Then”, like in this case, for an additional assertion.

Because of that, it is crucial to create test scenarios, as they can really show what we test and cover.

A wrong example

Feature:Shopping cart

Scenario: Test discount code functionality

Given the user opens Chrome browser And the user navigates to "https://shop.example.com/login"

And the user enters "testuser@mail.com"

in the email field And the user enters "Password123!" in the password field

And the user clicks the login button

And the user waits 3 seconds

And the user searches for product ID "SKU-8842"

And the user clicks "Add to Cart"

And the user clicks the cart icon

When the user types "SAVE20" into the input with id "promo-code-field"

And the user clicks the button with class "apply-btn"

Then the element with id "total-price" should contain "$96.00"

And the database table “orders” should have a new discount record

This type of test isn’t a real way to leverage BDD, and it’s the wrong approach, because it doesn’t express a specific Scenario as a business requirement but instead uses Gherkin as a bunch of different steps. For a person who wrote it, it can be quite clear, but for the whole team, it’s too long and unclear. Keep in mind that Steps should define actions, and the code should be hidden behind business-simple actions.

What if BDD is only used by us as the test automation team?

If we don’t use BDD for the whole team and it’s only an additional layer of abstraction that is used by an automated tester or tests, then in this case it can be inefficient to use it because apart from the code, we need to maintain this additional layer.

Also, beyond BDD, we have a few options in Playwright to use something which can be simpler but, in a lot of cases, more efficient:

Test Steps & logging

We can use test steps or additional logging as a very useful mechanism to describe particular actions in Playwright tests, even if it’s not possible to describe them. Also, we have a bunch of reporting tools, such as Allure or ReportPortal, which can help us report our automated tests to the team. Apart from these ideas, Trace Viewer is available out of the box and can show our automated tests clearly.

What if I still want to incorporate BDD in my project?

If we talk about using TS with Playwright, we have at least two options:

1) Playwright BDD

It’s one of the newest libraries that allows us to use BDD with Playwright in a more modern way. This results from the fact that beneath we can use the native Playwright runner. Why is it so important? Because of that, we can use Playwright native features, e.g., sharding. 

Benefits

The idea of this library is quite convenient. Playwright BDD can convert BDD scenarios into test files, which allow us to run them as standard tests. As a result, functions like :

• Visual Regression,
• Fixtures and many more are available

You can check it out there https://github.com/vitalets/playwright-bdd

Disadvantages

This library has been developed by a single person, so there is a risk that it will be abandoned or lack proper support.

Cucumber

This is the most popular library for using BDD in a project. Nowadays, Cucumber supports several different technologies and programming languages. However, in this context of using Cucumber with Playwright, unfortunately, not everything works well.

Cucumber has its own runner, which doesn’t allow the use of all of Playwright’s capabilities, which are built into the Playwright test runner. In this case, Playright is used by the library, not the tuner, so there are a few things that won’t work. Some links can explain to you more about what’s available https://playwright.dev/docs/library#key-differences

Benefits

Recognition on the market, a big community

If we talk about the Playwright world in the TS context that Playwright-BDD library is better because it supports all functions that are beneficial in Playwright. Based on my experience, a threat about a potential abandonment of this project is quite low because the author of this solution figured out a quite interesting idea of how Playwright-BDD creates feature files, so it should be possible to develop that.

Disadvantages

„Can we use XXX from playwright in the playwright-cucumber project?

The playwright-cucumber project started when playwright was a browser automation library. It did not have a test runner; Cucumber-JS was used as the test runner, and PW was used for the automation. Since then, PW added their amazing PW test library, which is a test runner. But, sadly, it overlaps the functionality provided by cucumber-js. Therefore, you need to make the decision now of which runner you want to run: cucumber for BDD-style tests or PW test for “normal” tests. Some of the features provided by PW test are also available in cucumber-js, such as parallel run and different configurations (profiles in cucumber-js terms), but may require a different configuration.

„ source https://github.com/Tallyb/cucumber-playwright/tree/master

One of the most popular boilerplate projects for using Playwright and Cucumber clearly defines that not all functions will work.

How to use Gherkin syntax in Visual Studio Code / Cursor?

If we want to see that our syntax is highlighted, we need to use an additional plugin for doing it. There are plenty of plugins that can help you. I recommend using this one below, but it’s up to you.

What about formatting our syntax in feature files?

As you probably know, the process of formatting code is useful because then it’s easier to understand what is going go. In feature files, we can use, e.g., prettier.

export default {

  plugins: ['prettier-plugin-gherkin'],

};

Summary

In this part of this series of articles, I wanted to explain to you how to think about using BDD because I see a necessity to talk about it. In the next post, I’m going to show you how to create a simple BDD test with Playwright. If you use another approach or do you have your observations about using BDD in projects, please share your perspectives in a comment.