Project roadmap for 2024

[vitalets]

I'd like to share my thoughts on playwright-bdd development in 2024.
There are 3 main directions:

1. Become less dependent on Cucumber internals
   Currently feature files and step definitions are loaded using Cucumber internal functions. It has several downsides:

   • changes in Cucumber can break playwright-bdd (as it was in Bug: Tests failing with latest version install due to changes in Cucumber package #80)
   • tricky run for ESM: need to pass NODE_OPTIONS: '--loader ts-node/esm --no-warnings' for Cucumber although Playwright handles ESM internally without ts-node
   • need to configure importTestFrom manually, impossible to have several test instances (see Feature: support several custom test instances #46)
   • performance: each Playwright worker loads full Cucumber package although runner is not used

   All these points will be resolved if playwright-bdd will load features and step definitions by own code. For features it can rely only on @cucumber/gherkin and for step definitions it can re-use Playwright's methods for loading test files. Actually, playwright-bdd already uses Playwright's import for loading steps in decorator syntax.

2. Support Cucumber reporters
   Playwright HTML reporter is not the best option for showing BDD test results, it is not designed for it. Background steps are hidden inside beforeHooks (see Question: how to move "background" step out of "beforeHooks" #78), Scenario Outline requires titles setup (see Feature: Scenario outline with examples in the title #67), there are unneeded details (e.g. fixtures). Cucumber's HTML reporter is definitely better for BDD and was proposed a long time ago (see Support Cucumber reporters #9). Current idea is to support Cucumber's message formatter and then use it for all other Cucumber compatible reporters and test automation tools (see Feature: Cucumber.js json Report generation #82). To validate messages output playwright-bdd should pass Cucumber compatibility-kit. It's important to generate Cucumber messages from Playwright's Blob output, because it allows to shard test runs and finally build Cucumber report with Playwright's merge reports command.

3. Create a tool for writing BDD scenarios
   This is more an experimental idea. I think about creating an online tool for writing BDD scenarios during collaboration sessions. It should have a simple UI and help people to quickly compose BDD scenarios following the best practices. Additionally, you can import steps from bddgen export command and use them for inline suggestions to speedup the process.
   The closest existing service is CucumberStudio, but it is not free and has a complicated UI (imho). If you know other similar services, feel free to share in the comments.

Any your ideas and thoughts are welcome here or in the corresponding issues!

[ronvoluted]

3. Create a tool for writing BDD scenarios
   If you know other similar services, feel free to share in the comments.

It's not Gherkin or E2E but for some good precedent on collaboration, good DX, nice design and support for various imports/exports there is Stately, a UI for XState finite state machines.

[pateljigar]

Many teams have very common requirement to pass test data in the *.csv, *.xls, *.xml or *.json for different scenarios in the feature files. Currently we have a limitation of doing data driven testing using data tables only. This is really limiting lots of teams to design real life data driven tests.

can we please prioritise this in upcoming releases??

[vitalets]

Currently we have a limitation of doing data driven testing using data tables only

@pateljigar could you provide an example?