[Feature] BDD implementation with Playwright test runner

[ShanmukhaGajula]

Our team has a case to use the BDD test, Playwright has any plan to add their own BDD implementation using the playwright test runner? That would be great if to have.

This can help many people who want to use BDD along with Playwright. That's where cucumber became popular 😉

[vitalets]

I've implemented BDD testing with Playwright runner for Node.js. Published it as playwright-bdd npm package. It provides bddgen CLI that allows to convert existing Cucumber features into Playwright tests:

Example of generated test

From ```gherkin Feature: Playwright site Scenario: Check title Given I open url "https://playwright.dev" When I click link "Get started" Then I see in title "Playwright" ``` To ```js import { test } from 'playwright-bdd'; test.describe('Playwright site', () => { test('Check title', async ({ Given, When, Then }) => { await Given('I open url "https://playwright.dev"'); await When('I click link "Get started"'); await Then('I see in title "Playwright"'); }); }); ```

When tests are generated Playwright config can read them and run as usual. For each test playwright-bdd creates Playwright-powered Cucumber World and passes it to step definitions. This allows to use Playwright objects (e.g. page) in Cucumber steps:

Example of step definition

```ts import { expect } from '@playwright/test'; import { Given, When, Then } from '@cucumber/cucumber'; import { World } from 'playwright-bdd'; Given('I open url {string}', async function (this: World, url: string) { await this.page.goto(url); }); When('I click link {string}', async function (this: World, name: string) { await this.page.getByRole('link', { name }).click(); }); Then('I see in title {string}', async function (this: World, keyword: string) { await expect(this.page).toHaveTitle(new RegExp(keyword)); }); ```

Finally, you can run BDD tests as a single command:

npx bddgen && npx playwright test

I'd like if someone try and share feedback on that.

[PavanMudigondaTR]

@vitalets I am going to try this today and I will let you know by Monday.

[PavanMudigondaTR]

@vitalets It seems okay to me at high level. I will spend more time in coming day to explore If I could use this. But could you tell me if we can use the Outline Feature with test data in feature files ?

[vitalets]

@vitalets It seems okay to me at high level. I will spend more time in coming day to explore If I could use this. But could you tell me if we can use the Outline Feature with test data in feature files ?

Yes. Scenario Outline is supported and converts into several tests with the same name.

[PavanMudigonda]

@vitalets It seems okay to me at high level. I will spend more time in coming day to explore If I could use this. But could you tell me if we can use the Outline Feature with test data in feature files ?

Yes. Scenario Outline is supported and converts into several tests with the same name.

This is awesome achievement. I wish playwright team can accept your solution as community contribution. I am going to test this in detail next week.

[PavanMudigondaTR]

@vitalets I realized the tests are getting duplicated when I used this pattern that the only caveat I have seen so far. I use an automation pattern to synchronize tests from Feature Files to Azure DevOps TestPlans that stores the parameters and does't duplicate.

Since it will take another year or two for playwright team to implement this feature request officially, I would like to start using your pattern. I hope any migration to new framework would be easier later on.

[vitalets]

@vitalets I realized the tests are getting duplicated when I used this pattern that the only caveat I have seen so far. I use an automation pattern to synchronize tests from Feature Files to Azure DevOps TestPlans that stores the parameters and does't duplicate.

@PavanMudigondaTR could you create an issue with details and we will think what we can do. Maybe wrap into another test.describe during test generation.

[winnie-sg]

Any update for this feature, please?

[gegoncalves]

@pavelfeldman @aslushnikov Sorry to disturb you guys. Does PW team has any plan to include this one in the roadmap?

Thanks for the good work 😄

[Niitch]

I've created a wrapper that makes the Playwright test runner handle the Gherkin syntax. It's published here : gherkin-wrapper

The package allows to register "step definition" functions in a Cucumber-like fashion and then run your tests using the playwright test CLI.

[jan-molak]

Hello all! It's great to see so many people interested in BDD and making Playwright support Gherkin syntax! However, I'm not sure if making Playwright Test dynamically generate code is even necessary.

Allow me to elaborate. Cucumber is much more than just the Gherkin parser; It has a runner that offers parallel test execution, supports tagging and filtering scenarios using tag expressions, integrates with numerous reporters, third-party plugins, not to mention project management tools, code editors and collaboration tools. Cucumber.js also has a dedicated VS Code extension that supports Gherkin auto-completion.

Making Playwright Test try to replicate all that seems like a lot of work that could've been avoided by improving the support offered by Playwright to other test tools, such as Cucumber.js.

In fact, playing to the strengths of both tools is what I do with Serenity/JS and what I'll attempt to show at a high level in this post.

TL;DR - check out https://github.com/serenity-js/serenity-js-cucumber-playwright-template

Integrating Cucumber.js with Playwright

What I love about Playwright is that we can integrate it with Cucumber.js just like any other library.

To do that, we need to:

1. launch the Playwright browser before we start the test run (we only need one browser since we can achieve test isolation using Playwright Contexts),
2. create a Context and a Page for each scenario and make them available in Cucumber step definitions,
3. close the Playwright browser when the test run is finished.

We can achieve 1. and 3. using BeforeAll and AfterAll hooks:

import {AfterAll, BeforeAll} from '@cucumber/cucumber';
import * as playwright from 'playwright';

let browser: playwright.Browser;

BeforeAll(async () => {
    browser = await playwright.chromium.launch({
        headless: true,
    });
});

AfterAll(async () => {
    if (browser) {
        await browser.close();
    }
});

If we wanted to make it more fancy, we could use a custom World and use lazy initialisation to launch the browser and initialise the page:

import {AfterAll, Before, setWorldConstructor, World} from '@cucumber/cucumber';
import * as playwright from 'playwright';

class CustomWorld extends World {
    private static browser?: playwright.Browser;
    private page: playwright.Page;

    async getPage(): Promise<playwright.Page> {
        if (! this.page) {
            const browser = await this.getBrowser();
            const context = await browser.newContext();
            this.page = await context.newPage();    
        }
        return this.page;
    }

    private async getBrowser(): Promise<playwright.Browser> {
        if (! CustomWorld.browser) {
            CustomWorld.browser = await playwright.chromium.launch({
                headless: true,
            });
        }

        return CustomWorld.browser;
    }

    static async shutDown(): Promise<void> {
        await CustomWorld.browser?.close()
    }
}

setWorldConstructor(CustomWorld);

AfterAll(async () => {
    await CustomWorld.shutDown();
})

With the above in place, we can define Cucumber steps like this:

Given('I want to learn about Playwright', async function (this: CustomWorld) {
    const page = await this.getPage()
    await page.goto('https://playwright.dev')
    // and so on
})

You'll notice that I use a similar approach in the Serenity/JS + Cucumber.js + Playwright template.

Limitations

Playwright extension for VS Code, quite understandably, relies on Playwright Test and doesn't support running tests with standard Cucumber.js, nor any other test runner.

What would be awesome 🤩 is if developers of other VS Code extensions, such as Cucumber.js, could somehow plug into the excellent toolchain offered by the Playwright extension for VS Code to run and debug test scenarios.

I'm not sure how we could do it, but I'd be happy to contribute to this effort if this is something the Playwright Team was interested in? @mxschmitt @aslushnikov?

[yaffol]

Yes, this is exactly what I want! I am wary of moving away from cucumber as a test runner for BDD scenarios, given the extensive toolchain it offers and lots of things that plug into it, plus it's 'already there'.

I use Serenity-js and can attest to its integration with cucumber. The missing parts are as @jan-molak outlined - there is not integration with the playwright extension for vscode, and that is a shame when you compare the experience of running BDD scenarios via cucumber (even with the excellent Serenity/bdd reports) and running tests via the VS code extension (or - even more apparent maybe - running them via the GREAT new UI mode).

I am totally sold on BDD as a development style, and I love what it brings to the design and exploration process - but I also really like the ease of debugging and the accessibility of tests run via the VS code extension or the UI mode. If these facets could be brought together, I think we would have a really compelling BDD tool suite. I'd be very happy to contribute to this effort too.

[VitaliyPotapov]

Allow me to elaborate. Cucumber is much more than just the Gherkin parser; It has a runner that offers parallel test execution, supports tagging and filtering scenarios using tag expressions, integrates with numerous reporters, third-party plugins, not to mention project management tools, code editors and collaboration tools. Cucumber.js also has a dedicated VS Code extension that supports Gherkin auto-completion.

Making Playwright Test try to replicate all that seems like a lot of work that could've been avoided by improving the support offered by Playwright to other test tools, such as Cucumber.js.

I think the idea is not to replicate from scratch all things you mentioned. Most of it is already implemented in Playwright runner. It supports parallel test execution and sharding, tagging and filtering scenarios, has a lot of built-in reporters and third-party integrations. All tools for writing BDD scenarios remain the same as there is no need to re-invent Gherkin syntax.

We can achieve 1. and 3. using BeforeAll and AfterAll hooks... If we wanted to make it more fancy, we could use a custom World and use lazy initialisation to launch the browser and initialise the page

Playwright runner performs all these initializations/cleanup for you automatically - this is one of the main benefits! And with custom fixtures the code become far more clear and explicit compared to before* / after* hooks and custom World context.

[NikkTod]

Guys, I understand that you do not want to migrate as you have to set up things again, but playwright runner is already at the level of the cucumber runner if not better. You can have your filtering scenarios, integration with custum reporters, parallel test execution, dependency projects, and on top of that very cool features from vs code extention, UI mode and Visual testing. All that is like you install playwright and you have it, no need to integrate or complex set up. I know that it is difficult to make one tool, which can do anything, but I always prefer not to have so many different frameworks.

For me, with this feauture we just want support for Gehrkin/BDD syntax, we already have all the other things with playwright runner.

I have tried playwright-bdd from and gherkin-wrapper, both solutions are doing a great job and few things are left to be fixed and implemented.

As far as I understood if playwright team sees that those kind of bdd wrapper projects are actively used they would integrate in future and we would get our in-build support.

[arvinder06]

Cucumber js is great with playwright, however we lose the capability to use playwright features like visual testing, sharding etc. Would love to have BDD native to playwright so that we can run BDD tests using playwright runner.

[devpro]

cucumber-tsflow works really well. I have implemented a solution thanks to Playwright (which is so great), Cubumber.js and cucumber-tsflow.

What is missing is the integration with Playwright CLI (include tests in reports) and Playwright VS Code extension (run/debug).

Here is what it looks like:

• Gherkin: acceptance/admin-ui/features/login.feature

• Code behind: acceptance/admin-ui/step-definitions/user-auth.step-definition.ts

It all works fine with Playwright thanks to this two classes:

• src/execution-flow/base.step-definition.ts

import { chromium } from '@playwright/test';
import * as dotenv from 'dotenv';
import { after, before, binding } from 'cucumber-tsflow';
import { SessionContext } from './session.context';

@binding([SessionContext])
export class BaseStepDefinition {
  public constructor(protected sessionContext: SessionContext) { }

  @before('@WebApp')
  public async beforeAllWebAppScenarios(): Promise<void> {
    dotenv.config();
    const browser = await chromium.launch();
    this.sessionContext.browser = browser;
    const context = await browser.newContext({ ignoreHTTPSErrors: true });
    this.sessionContext.browserContext = context;
    this.sessionContext.page = await context.newPage();
  }

  @after('@WebApp')
  public async afterAllWebAppScenarios(): Promise<void> {
    await (this.sessionContext.browserContext ?? (() => { throw new Error('browserContext is null'); })()).close();
    await (this.sessionContext.browser ?? (() => { throw new Error('browser is null'); })()).close();
  }
}

• src/execution-flow/session.context.ts

import { Browser, BrowserContext, Page } from '@playwright/test';

export class SessionContext {
  page: Page | null = null;
  browser: Browser | null = null;
  browserContext: BrowserContext | null = null;
  current: unknown;
}

[NikkTod]

@devpro great effort on this one, thanks for sharing it, could be very useful for people who want to stay with cucumber js runner. But yet again as you mentioned there are some missing features as with other solutions.

Don`t get me wrong, the cucumber-tsflow is great and I see a lot of people are using it.

The idea with this ticket and the mentioned by me current solutions is not to miss anything from playwright runner features.

[Tallyb]

I just looked thru this thread, and was surprised to find out that my repo was not mentioned: https://github.com/Tallyb/cucumber-playwright It has been around for 2 years and got quite a few forks used as a starter project. (It used to be in the description of the cucumbers channel on Slack, and got lost when moving to Discord). While I agree with @jan-molak that cucumber is a full-featured runner, it lags behind PW test runner in more than one aspect. First, you can define a before feature hook (only before scenario). In the same way you can only define background steps for each scenario, but not at the feature level. Also, sharding, fixtures, and of course - UI mode. (as a note, this template was created when Playwright was only the library, and did not have the test runner)

[jan-molak]

@Tallyb - I agree with your assessment, echoed by many others in this thread - there are significant differences between the Cucumber.js runner and Playwright Test. I also share your sentiment towards Playwright Test - I think it offers a brilliant developer experience and I was well impressed seeing how it brought the idea of PyTest fixtures to the world of JavaScript.

It feels like for BDD practitioners, the ideal solution could be:

1. to have Playwright Test become a fully-fledged Cucumber runner, so parse .feature files, understand tags, integrate with external tools (like the numerous Jira plugins), provide its excellent DI mechanism in step definitions, and so on. As @VitaliyPotapov mentioned, a lot of the infrastructure needed to achieve this might exist in Playwright Test already. Bringing first-class support for parsing feature files and injecting Playwright fixtures into step definitions would help to bridge the gap and addresses the points brought up by @NikkTod
2. find an alternative that doesn't require folks to use Cucumber or Gherkin at all, yet brings the same benefits of code encapsulation and improved reporting to their Playwright Tests

While I fully support option 1 (just as much as I support improving support for Playwright in the original Cucumber project), I've been working recently on option 2 and wanted to share my results so far in the hope of your feedback.

When do you need Cucumber/Gherkin?

As opposed to Playwright Test, Cucumber is a collaboration tool, not a test automation tool. Its main benefit is that it allows you to express executable specifications of your system in one of the 79 supported languages instead of just code.

This can be incredibly helpful if your audience prefers to use their native language, like French, Spanish, Arabic, or Japanese, to define their acceptance tests instead of reading your code written in English. Another use case is when your business sponsors/organisation uses external tools like Jira to collaborate on or review Gherkin scenarios without having to access the code or if they simply prefer using Gherkin to express the scenarios instead of doing that directly in code.

All those cases are perfectly valid and quite popular.

However, what if your intended audience simply needs readable reports and doesn't care how they're generated or what tool you use to make them? What if you use techniques like Example Mapping or Feature Mapping to discover your requirements and don't actually need to capture them in Gherkin?

What if you could use Playwright Test to write highly readable code and produce test reports as good as the ones offered by Cucumber? What if it all worked with Playwright Test UI Mode, Trace Viewer, and HTML reports?

How Serenity/JS Screenplay Pattern improves readability

I've been recently working on integrating Serenity/JS with Playwright Test and leveraging features introduced in Playwright 1.33/1.34 to extend Playwright's reporting capabilities and make its reports more human-friendly.

You can read more about it in my article on Serenity/JS support for Playwright Test UI Mode.

In short, I'm leveraging Playwright test.step to translate Serenity/JS Screenplay Pattern tasks into Playwright "steps" without the developer ever having to invoke test.step directly in their code.

An example todo list app scenario implemented using Serenity/JS Screenplay Pattern and using Playwright Test looks like the listing below (see full example):

import { describe, it } from '@serenity-js/playwright-test';

describe('Recording items', () => {

    describe('Todo List App', () => {

        it('should allow me to add todo items', async ({ actor }) => {
            await actor.attemptsTo(
                startWithAnEmptyList(),

                recordItem(TODO_ITEMS[0]),

                Ensure.that(itemNames(), equals([
                    TODO_ITEMS[0],
                ])),
            );
        });
    });
});

As you can hopefully see above, even though the scenario is not expressed in Gherkin, it's still perfectly readable to an English speaker. Plus, you can run it using the Playwright Test extension for VS Code.

With Serenity/JS, developers compose tasks like recordItem from sub-tasks like this:

export const recordItem = (name: Answerable<string>): Task =>
    Task.where(d `#actor records an item called ${ name }`,
        Enter.theValue(name).into(newTodoInput()),
        Press.the(Key.Enter).in(newTodoInput()),
        Wait.until(itemNames(), contain(name)),
    )

Each low-level sub-task (or an "interaction", in Serenity-speak) maps to a Playwright API call, which you can see together with developer-defined tasks in Playwright reports (including Playwright UI Mode and Trace Viewer):

If you'd like to explore Serenity/JS approach to writing highly-readable tests, you might want to try the Serenity/JS + Playwright Test tutorial (you can even run it directly in your browser, no local installation required).

Serenity/JS Screenplay Pattern APIs for Playwright Test are not a replacement; they're an extension designed to work alongside "native" Playwright scenarios and bring the benefits of highly readable and easy-to-understand test code to Playwright Test suites.

Of course, teams using Cucumber can also use Serenity/JS under the hood as demonstrated in this example, making Screenplay tasks a bridge between your test scenarios and the test runner.

I hope it's useful!

[Terence625]

I like cucumber and am using it in my daily work, but I think no need to bind BDD strictly with cucumber and Gerkin syntax. In my opinion, implementing BDD in automation tests is mainly about binding test scenarios and steps in human language with automation test codes, and after test run, generating a test report with test scenarios and steps. Both the input and output of automation test are driven by business requirement, which can be written in Gerkin syntax or any other styles your business analyst/quality analyst like to use.

So after walking through all playwright docs and apis, I found that playwright provided enough flexibility for us to customise the test workflow. Here we can leverage its test.describe and test.step to achieve BDD implementation, using playwright's todo test example:

todo-step-definitions.ts

import { test, expect, type Page } from "@playwright/test";
export const step_createTodoItem = async (page: Page, todo: string) => {
  await test.step(`Create todo: ${todo}`, async () => {
    await page.getByPlaceholder("What needs to be done?").fill(todo);
    await page.getByPlaceholder("What needs to be done?").press("Enter");
  });
};
export const step_checkTodoItem = async (page: Page, todo: string) => {
  await test.step(`Check todo: ${todo}`, async () => {
    await expect(page.getByText(todo)).toBeVisible();
  });
};
export const step_createAndCheckTodoItem = async (page: Page, todo: string) => {
  await step_createTodoItem(page, todo);
  await step_checkTodoItem(page, todo);
};

demo-todo-app.spec.ts

import { test as base, expect, type Page } from "@playwright/test";
import {
  step_createTodoItem,
  step_checkTodoItem,
  step_createAndCheckTodoItem,
} from "./todo-step-definitions";
const test = base.extend({
  page: async ({ page }, use) => {
    await page.goto("https://demo.playwright.dev/todomvc");
    await use(page);
  },
});
test.describe("New Todo", () => {
  test("should allow me to add todo items", async ({ page }) => {
    await step_createTodoItem(page, "buy some cheese");
    await step_checkTodoItem(page, "buy some cheese");
    await step_createTodoItem(page, "feed the cat");
    await step_checkTodoItem(page, "feed the cat");
  });
  test("should allow me to add todo items nested steps", async ({ page }) => {
    await step_createAndCheckTodoItem(page, "buy some cheese");
    await step_createAndCheckTodoItem(page, "feed the cat");
  });
});

The above implementation clearly shows test scenarios and steps, with all the benefits from playwright test runner

And it can also do something that cucumber cannot do which is nested steps, you can combine multiple small steps into one large step, which is a pain point when using cucumber.

This is just a simple example, there are infinite possibility to customise your own BDD implementation with playwright. I'm sure your can import test scenarios and steps from other test management platform and use source map based approach to translate into playwright titles in test.describe and test.step

[jake-davisOVO]

Cucumber js is great with playwright, however we lose the capability to use playwright features like visual testing, sharding etc. Would love to have BDD native to playwright so that we can run BDD tests using playwright runner.

Perfectly summed up, are we any closer to having this?

[NikkTod]

Hi @jake-davisOVO

You can try those two framework solutions, they are achieving the same goal with a bit different approach. Both are using playwright runner.

-> playwright-bdd I am currentlly testing it and as far as I see the things I need are working correctlly. This project converts feature files and generates playwright test files (mainly for test debugging purpose). -> gherkin-wrapper Waiting on some things to be fixed, concerning UI mode and VSCode extention, but this project looks very promising. The approach in it is to be like a wrapper, so it converts feature files on-the-fly when running the test with the playwright runner.

Would be nice if more people try those to approaches and raise bugs where needed.

[jake-davisOVO]

Thanks for getting back to me @NikkTod,

I am certainly open to using something like playwright-bdd. I guess my concern is that if the updates for the project suddenly stop, we could be left in a hairy position. I can see it's being developed by a team of two (not to discredit them at all, it looks amazing) so just creates some risk.

It feels like it would create a lot of reassurance if the Playwright team just baked all of this into the product.

What do you think?

[NikkTod]

@jake-davisOVO, I totally agree, it is better if playwright team start supporting it. As far as I understood they are following closely the development of the bdd projects and could in future integrate one of them within Playwright.

[Yeya9742]

Seriously cucumber-js should be supported by the Playwright team, too sad this is taking too long :(

[ysnblgn]

Is there any way of adapting the UI mode of playwright to understand cucumber features? E.g. Cypress Watch mode

[RogerDat1]

playwright test runner should start supporting for BDD framework . We are missing out the potential and benefit of running playwright through playwright.config.ts(playwright runner file ) rather we have to use cucumber-js . Because of this we are missing out parallel execution , integrating reporting portal io with our framework . using cucumber runner file and playwright as a tool is not making our framework scalable .

Playwright team ... please integrate BDD with playwright and make it native to playwright . so that we can use playwright test runner to its full potential .

[dangnguyen92]

I am really surprised that Playwright does not yet support BDD/Cucumber. It would mean a lot to the testing community if it were integrated.

[ljelonek]

I was working on Playwright+Cucumberjs PoC in my project (we are currently using WebDriver.IO but would really love to utilize automated waits and other goodies 🙃). Here is a quick summary of things that prevent us from going live:

• Cubumber does not respect Playwright settings (or the other way around?).
  • It is not possible to override assertion timeout globally. I was able to set it up on each assertion (which was nice for a PoC) and possibly, we could write a wrapper library that does that. But this would mean significant code pollution that is not acceptable.
  • It is not possible to override step timeout globally. Your test takes longer than default 30 seconds? Great, your test steps will be skipped and an error will be thrown in AfterScenario (also, you will not have screenshot or anything).
• Logs look awful on test report summary. I guess it is something that I could work on, but colured syntax does not render well initially.

Despite that, I must say that it was a cool ride and I am really looking forward to Playwright BDD or more support for Cucumberjs.

[jake-davisOVO]

Can someone from the playwright team confirm if this is ever going to be in scope? There is clearly a lot of desire for it!

[jan-molak]

• Cubumber does not respect Playwright settings (or the other way around?).

Well, in all fairness to both tools, Cucumber is a separate test runner, so knows nothing about Playwright, nor does Playwright know anything about Cucumber 😄

• It is not possible to override assertion timeout globally. I was able to set it up on each assertion (which was nice for a PoC) and possibly, we could write a wrapper library that does that. But this would mean significant code pollution that is not acceptable.

That's an interesting find. I think it's because Playwright Test creates its own version of expect so that it can rely on the global currentTestInfo. Of course, there's no equivalent of that in the Cucumber land, hence the issue.

A Cucumber version of expect would need to rely on Cucumber World or some other global configuration mechanism.

• It is not possible to override step timeout globally.

You can use setDefaultTimeout to accomplish that, I believe.

• Logs look awful on test report summary. I guess it is something that I could work on, but colured syntax does not render well initially.

Yeah, that's because Playwright Test embeds character escape sequences in error diffs so that they look better in VSCode (at least I'm guessing that this was the reason).

It would be nicer for Playwright to attach serialised information about actual and expected values, a'la Mocha/Jasmine (I reported a similar issue at #26848), but then that would require changes to how the entire error serialisation mechanism works in Playwright. Not to mention it's not trivial to turn actual/expected pair into a nice diff as that depends on the type of assertion, so I fully appreciate the complexity.

You might want to have a look at Serenity/JS Cucumber + Playwright template if you want nice reports and diffs without character escape sequences.

Despite that, I must say that it was a cool ride and I am really looking forward to Playwright BDD or more support for Cucumberjs.

Agreed. I think to have this high level of integration between Cucumber.js and Playwright like we have with Playwright Test, Playwright would need to create a dedicated runner for Cucumber feature files.

If that were an option, I'd love to see Playwright Test-style dependency injection available in Cucumber steps 🤩

[JoaoEnesGoncalves]

it is like something incomplete, for one hand playwright is a great tool but on the other hand it is missing BDD support. As a tester I see this gap as a major backlog improvement issue.

[Phonesis]

Like many here, I've developed a customised framework which uses Playwright to drive Cucumber Feature files. As part of this, Cucumber is the test runner. As a result, we are missing out on all the great Playwright Test runner features.

A BDD option / config / runner would be absolutely incredible! This is perhaps the only glaring omission Playwright currently has right now.

Being able to run Cucumber Feature files in parallel using the worker logic which makes Playwright Test so special...

[JSLadeo]

So many asking for support cucumber/BDD, glad to not be alone. I was in live , and asking for that and get the ui mode but the answer was not enough demand... this feature prove the contrary! 171 like etc, perhaps we shoud form a faction and work on that, cypress use it, so impossible for team of my project to switch cause of that

[med8bra]

BDD would be a great add-on to Playwright. Since cucumber has its own test runner, it may be limiting compared to playwright test runner. It would make sense for playwright to support some sort of BDD testing, or at least offer better integration with cucumber

[ZhouZhengCarlos]

Looking forward for this BDD implementation for playwright, in my current job it is useful for our QAs that doesnt have Code expertise

[ahnpnl]

This issue is actually a major blocker for my team to switch to Playwright

[alescinskis]

This issue is actually a major blocker for my team to switch to Playwright

I would recommend taking a look at https://github.com/vitalets/playwright-bdd as lack of bdd was a deal breaker for me, but then I've stumbled upon this project.

[LANDG-MartinP]

https://github.com/vitalets/playwright-bdd looks interesting but I wonder if there are any limitations? I know, for example, it only recently introduced support for Hooks?

Does it generate the Playwright HTML report? Can it be used to fully shard tests for parallel execution (test by test, not file by file aka cucumber.js)

[odeatomas]

Read the documentation all your questions are covered.

On Thu, 14 Dec 2023, 10:01 Martin Poole, @.***> wrote:

https://github.com/vitalets/playwright-bdd looks interesting but I wonder if there are any limitations? I know, for example, it only recently introduced support for Hooks?

Does it generate the Playwright HTML report? Can it be used to fully shard tests for parallel execution (test by test, not file by file aka cucumber.js)

— Reply to this email directly, view it on GitHub https://github.com/microsoft/playwright/issues/11975#issuecomment-1855539011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHG64IC2YIB3UT7QOS7DQSTYJLE53AVCNFSM5N6IWVZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVGU2TGOJQGEYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jakedavis219]

I've put together a small framework using playwright and the implementation off bdd/gherkin to organise tests if people want to take a look: https://github.com/jakedavis219/playwright-bdd-typescript-framework

This is the closest I could get without any BDD features being offered by playwright.

[nokrashy-pwc]

We need this ASAP please!

[asdfsafd]

No problem using the playwright test lib with the Cucumber test runner. It's the playwright test runner features we want to benefit from using our Gherkin Scenarios.

[tcydik]

https://github.com/vitalets/playwright-bdd looks interesting but I wonder if there are any limitations? I know, for example, it only recently introduced support for Hooks?

Does it generate the Playwright HTML report? Can it be used to fully shard tests for parallel execution (test by test, not file by file aka cucumber.js)

This library went a long way since this post. Have a look at it again.

[MarcHendo]

Currently using a combination of typescript, playwright and cucumber js. So far its working well, but native support would be great. If it could somehow be integrated into the visual code extension it would take playwright to the next level.

[acmetro]

Native support of BDD would be amazing!

[RichardCariven]

Native support of BDD would be amazing!

https://github.com/vitalets/playwright-bdd we are implementing that within our organisation and it is far far far better then any Playwright/Cucumber solution we have tried.

being able to use Fixtures and the playwright Config opens up so many more opportunities to make our behave tests far more flexible and simpler to maintain and run.

[Tallyb]

I was not aware of this: https://pypi.org/project/pytest-bdd/ can be an inspiration.

[MartinB134]

But if you want to share steps across multiple folders pytest-bdd will give you a world of pain. Somehow using a API Setup step for example only works If you share it via an increasingly bloated conftest.py. Also there is no ide integration. It works in the end, but it's painful.

Using behave feels like a massive improvement after switching, for also multiple other reasons.

Tally Barak @.***> schrieb am Do., 16. Mai 2024, 15:09:

I was not aware of this: https://pypi.org/project/pytest-bdd/ can be an inspiration.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/playwright/issues/11975#issuecomment-2115206120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHRH6QSTIIWLX5PE6GRNENDZCSVZPAVCNFSM5N6IWVZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJRGUZDANRRGIYA . You are receiving this because you commented.Message ID: @.***>

[LahiruMadhawa2020]

Eagerly waiting on this feature for a long time. Hoping to see it in an early future release.