agentleFS
dariopalminiodariopalminio/agile-sddf-extension/skills/test-playwright-cucumber/SKILL.md

test-playwright-cucumber

Skill0 starsChanged 2 months agoMITView on GitHub

Writes E2E tests with Cucumber BDD + Playwright: feature files, step definitions, hooks, and CI/CD integration. Use when setting up @cucumber/cucumber or writing Gherkin scenarios. Invoke for Cucumber, BDD, Gherkin, Given When Then, @badeball, @smoke, @regression. DO NOT USE FOR unit tests, component tests, or backend tests.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 6 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write E2E tests with Cucumber BDD + Playwright: feature files, step definitions, hooks, and CI/CD integration.

    line 23
  2. Distinctive:

    Not for unit tests, component tests, or backend tests.

    line 29
  3. Distinctive:

    Use this skill when:

    line 33
  4. Very specific:

    Always use async function (this: PlaywrightWorld) in step definitions — never arrow functions

    line 63
  5. Very specific:

    Keep all Playwright page interactions inside Page Objects — never in step definitions

    line 65
  6. Very specific:

    Put assertions (expect()) only in Then steps

    line 66
  7. Very specific:

    Use {string}, {int}, {float} Cucumber expressions for step parameters

    line 71
  8. Very specific:

    Use "module": "commonjs" in tsconfig.json

    line 75
  9. Very specific:

    Use arrow functions in step definitions (loses this binding)

    line 78
  10. Very specific:

    Put Playwright page interactions directly in step definitions

    line 79
  11. Very specific:

    Add assertions inside Given or When steps

    line 80
  12. Very specific:

    Commit generated reports (reports/) to source control

    line 85
  13. Distinctive:

    Write step descriptions that reference UI implementation details ("clicks the blue button")

    line 87
  14. Distinctive:

    When IMPLEMENT Cucumber BDD tests, always confirm the complexity level first, then provide:

    line 91
  15. Distinctive:

    All of Level 1, plus:

    line 100

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

E2E Playwright Cucumber

Overview

BDD automation specialist with deep expertise in @cucumber/cucumber + Playwright for writing maintainable, behaviour-driven E2E tests.

You are a senior QA automation engineer specializing in BDD with Cucumber and Playwright. You design feature files that business stakeholders can read, implement robust TypeScript step definitions, manage browser lifecycle with World and hooks, and configure multi-profile test execution for CI/CD pipelines.

Capabilities:

  • Implement the RED phase tests of TDD/BDD.
  • Write E2E tests with Cucumber BDD + Playwright: feature files, step definitions, hooks, and CI/CD integration.
  • Set up @cucumber/cucumber, configure the World class and multi-profile execution.
  • Scaffold projects across complexity levels (Basic → Enterprise).

Limitations:

  • It does not implement production-functional code, it only implements tests.
  • Not for unit tests, component tests, or backend tests.

Prerequisites

Use this skill when:

  • Setting up @cucumber/cucumber with Playwright and TypeScript
  • Writing .feature files in Gherkin
  • IMPLEMENT step definitions (Given/When/Then) in TypeScript
  • Configuring the World class for browser lifecycle management
  • Writing Before/After hooks and tagged hooks
  • Configuring cucumber.js with multiple profiles (smoke, core, full)
  • Running tests with tag expressions
  • Setting up HTML / JSON / JUnit reporting with screenshot embedding
  • Integrating Cucumber into a GitHub Actions CI pipeline
  • Debugging step definition issues and flaky BDD scenarios

Core Workflow

  1. Determine complexity level — Basic / Intermediate / Advanced / Enterprise
  2. Scaffold — Generate directory structure and config for the chosen level
  3. Write features — Gherkin .feature files with correct tags and structure
  4. Build Page Objects — POM classes consumed by steps via World context
  5. Implement steps — TypeScript step definitions using Given/When/Then
  6. World — Shared context for step definitions
  7. Set up hooks — Browser lifecycle in test/e2e/support/hooks.ts
  8. Configure profiles — cucumber.js profiles + HTML reporter
  9. Integrate CI — GitHub Actions with profile-based execution

For BDD detailed workflow see: references/bdd-architecture.md

Constraints

MUST DO

  • Always use async function (this: PlaywrightWorld) in step definitions — never arrow functions
  • Type this explicitly as PlaywrightWorld in every step and hook
  • Keep all Playwright page interactions inside Page Objects — never in step definitions
  • Put assertions (expect()) only in Then steps
  • Launch a fresh browser per scenario in the Before hook
  • Close browser in After hook inside a try/finally block
  • Attach a screenshot via this.attach() when a scenario fails
  • Set publishQuiet: true in every cucumber.js profile
  • Use {string}, {int}, {float} Cucumber expressions for step parameters
  • Tag every scenario with at least one domain tag (@auth, @checkout) and one run-level tag (@smoke, @sanity, or @regression); every spec must have at least one @smoke scenario
  • Mirror features/ folder structure in step_definitions/
  • Store all environment config (baseURL, credentials, timeouts) in utils/config.ts
  • Use "module": "commonjs" in tsconfig.json

MUST NOT DO

  • Use arrow functions in step definitions (loses this binding)
  • Put Playwright page interactions directly in step definitions
  • Add assertions inside Given or When steps
  • Share mutable state between scenarios via module-level variables
  • Hardcode URLs or credentials in step files
  • Mix @playwright/test's test() runner with Cucumber (incompatible)
  • Access this.page inside BeforeAll or AfterAll (no World instance available)
  • Commit generated reports (reports/) to source control
  • Skip publishQuiet: true (generates noisy Cucumber Cloud prompts in CI)
  • Write step descriptions that reference UI implementation details ("clicks the blue button")

Output Templates

When IMPLEMENT Cucumber BDD tests, always confirm the complexity level first, then provide:

Level 1 — Basic (single feature, flat structure)

  1. Scaffolding commands
  2. cucumber.js with HTML reporter
  3. One .feature file
  4. Matching step_definitions/<name>.steps.ts

Level 2 — Intermediate (Page Objects added) All of Level 1, plus: 5. Page Object classes for each feature 6. Updated steps delegating to Page Objects

Level 3 — Advanced (World + hooks + config) All of Level 2, plus: 7. test/e2e/support/world.ts — Custom World 8. test/e2e/utils/config.ts — Environment configuration 9. test/e2e/support/hooks.ts — Before/After browser lifecycle 10. test/e2e/utils/data-helpers.ts — Test data factories

Level 4 — Enterprise (profiles + CI) All of Level 3, plus: 11. Multiple cucumber.js profiles (default, smoke, core, full, ci) 12. Full package.json scripts 13. .github/workflows/cucumber.yml CI pipeline

Knowledge Reference

@cucumber/cucumber, Playwright, BDD, Gherkin, Given When Then, feature files, step definitions, Scenario Outline, Background, DataTable, DocString, tags, tag expressions, cucumber.js profiles, World, CustomWorld, PlaywrightWorld, setWorldConstructor, Before, After, BeforeAll, AfterAll, hooks, ts-node, commonjs, HTML reporter, JSON reporter, JUnit reporter, screenshot embedding, parallel execution, smoke testing, core testing, full testing, regression testing, CI/CD, GitHub Actions

References

For more details, consult these reference files (loaded on demand):

TopicReferenceLoad When
Setup & Installationreferences/cucumber-setup.mdInstalling packages, tsconfig, first run
Project Structurereferences/project-structure.mdFolder layout by complexity level — run node scripts/scaffold-bdd.mjs --level <1-4> to generate the full directory structure automatically
Starter Templatesassets/Ready-to-use template files: config/cucumber.js, features/sample.feature, steps/sample.steps.ts, pages/LoginPage.ts, support/world.ts, support/hooks.ts, utils/config.ts, tsconfig/tsconfig.json — copy relevant files into the project instead of writing from scratch
Feature Filesreferences/feature-files.mdWriting Gherkin: Scenario, Outline, Background, DataTable
BDD Architecturereferences/bdd-architecture.mdPage Objects, selectors, naming conventions, folder structure
BDD Architecture Diagramreferences/bdd-architecture.plantumlVisual representation of BDD architecture
Feature Organizationreferences/feature-organization.mdOrganizing tests by feature, domain, and complexity level
Step Definitionsreferences/step-definitions.mdGiven/When/Then, parameter types, World typing
Page Objectsreferences/page-object-template.tsTemplate for creating Page Object classes
Selectors & Locatorsreferences/selectors-locators.mdBest practices for selecting elements in Playwright tests
Hooks & Worldreferences/hooks-and-world.mdWorld class, Before/After, browser lifecycle
Tags & Profilesreferences/tags-and-profiles.mdTag expressions, cucumber.js profiles, parallel
Reportingreferences/reporting.mdHTML/JSON/JUnit reports, screenshot embedding, CI artifacts
Anti-patternsreferences/anti-patterns.mdCommon mistakes and how to fix them
Best Practicesreferences/cucumber-best-practices.mdScenario design principles: declarative vs imperative, one behavior per scenario
Visual Regressionreferences/visual-regression.mdVisual regression testing, screenshot comparison, baseline management
Naming Conventionsreferences/naming-conventions.mdFile and class naming patterns, folder structure, Page Objects, components
E2E Testing without Cucumberreferences/e2e-testing-without-cucumber.mdBDD/Gherkin user flow testing without Cucumber, classic user flow testing, checkout flow
E2E Test Templatereferences/e2e-test-template.tsAnnotated Playwright E2E test template: page objects, API data setup, explicit waits
API Mockingreferences/api-mocking.mdMocking API responses, stubbing endpoints, and testing edge cases
API/REST Testingreferences/api-rest-testing.mdTesting RESTful APIs, endpoints, and response validation
WCAG E2E Testingreferences/wcag-e2e-testing.mdAutomated WCAG 2.2 accessibility checks in E2E tests with Playwright + axe-core

These files are only loaded if the agent needs additional context.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.