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.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-backend-nestjsSkill
- code-frontend-library-reactSkill
- doc-changelog-generationSkill
- doc-design-generationSkill
- doc-domain-generationSkill
- doc-guardrail-generationSkill
- doc-policy-generationSkill
- doc-readme-generationSkill
- git-tbd-for-sddSkill
- git-worktrees-useSkill
- openspec-generate-baselineSkill
- openspec-init-configSkill
- security-auditSkill
- skill-masterSkill
- skill-test-evalsSkill
- test-cypress-cucumberSkill
- test-nestjs-jest-testing-moduleSkill
- test-nestjs-supertestSkill
- test-react-testing-librarySkill
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
- Distinctive: line 23
Write E2E tests with Cucumber BDD + Playwright: feature files, step definitions, hooks, and CI/CD integration.
- Distinctive: line 29
Not for unit tests, component tests, or backend tests.
- Distinctive: line 33
Use this skill when:
- Very specific: line 63
Always use async function (this: PlaywrightWorld) in step definitions — never arrow functions
- Very specific: line 65
Keep all Playwright page interactions inside Page Objects — never in step definitions
- Very specific: line 66
Put assertions (expect()) only in Then steps
- Very specific: line 71
Use {string}, {int}, {float} Cucumber expressions for step parameters
- Very specific: line 75
Use "module": "commonjs" in tsconfig.json
- Very specific: line 78
Use arrow functions in step definitions (loses this binding)
- Very specific: line 79
Put Playwright page interactions directly in step definitions
- Very specific: line 80
Add assertions inside Given or When steps
- Very specific: line 85
Commit generated reports (reports/) to source control
- Distinctive: line 87
Write step descriptions that reference UI implementation details ("clicks the blue button")
- Distinctive: line 91
When IMPLEMENT Cucumber BDD tests, always confirm the complexity level first, then provide:
- Distinctive: line 100
All of Level 1, plus:
≈ “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.
Files
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 theWorldclass 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/cucumberwith Playwright and TypeScript - Writing
.featurefiles in Gherkin - IMPLEMENT step definitions (
Given/When/Then) in TypeScript - Configuring the
Worldclass for browser lifecycle management - Writing
Before/Afterhooks and tagged hooks - Configuring
cucumber.jswith 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
- Determine complexity level — Basic / Intermediate / Advanced / Enterprise
- Scaffold — Generate directory structure and config for the chosen level
- Write features — Gherkin
.featurefiles with correct tags and structure - Build Page Objects — POM classes consumed by steps via World context
- Implement steps — TypeScript step definitions using
Given/When/Then - World — Shared context for step definitions
- Set up hooks — Browser lifecycle in
test/e2e/support/hooks.ts - Configure profiles —
cucumber.jsprofiles + HTML reporter - 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
thisexplicitly asPlaywrightWorldin every step and hook - Keep all Playwright
pageinteractions inside Page Objects — never in step definitions - Put assertions (
expect()) only inThensteps - Launch a fresh browser per scenario in the
Beforehook - Close browser in
Afterhook inside atry/finallyblock - Attach a screenshot via
this.attach()when a scenario fails - Set
publishQuiet: truein everycucumber.jsprofile - 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@smokescenario - Mirror
features/folder structure instep_definitions/ - Store all environment config (baseURL, credentials, timeouts) in
utils/config.ts - Use
"module": "commonjs"intsconfig.json
MUST NOT DO
- Use arrow functions in step definitions (loses
thisbinding) - Put Playwright
pageinteractions directly in step definitions - Add assertions inside
GivenorWhensteps - Share mutable state between scenarios via module-level variables
- Hardcode URLs or credentials in step files
- Mix
@playwright/test'stest()runner with Cucumber (incompatible) - Access
this.pageinsideBeforeAllorAfterAll(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)
- Scaffolding commands
cucumber.jswith HTML reporter- One
.featurefile - 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):
| Topic | Reference | Load When |
| Setup & Installation | references/cucumber-setup.md | Installing packages, tsconfig, first run |
| Project Structure | references/project-structure.md | Folder layout by complexity level — run node scripts/scaffold-bdd.mjs --level <1-4> to generate the full directory structure automatically |
| Starter Templates | assets/ | 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 Files | references/feature-files.md | Writing Gherkin: Scenario, Outline, Background, DataTable |
| BDD Architecture | references/bdd-architecture.md | Page Objects, selectors, naming conventions, folder structure |
| BDD Architecture Diagram | references/bdd-architecture.plantuml | Visual representation of BDD architecture |
| Feature Organization | references/feature-organization.md | Organizing tests by feature, domain, and complexity level |
| Step Definitions | references/step-definitions.md | Given/When/Then, parameter types, World typing |
| Page Objects | references/page-object-template.ts | Template for creating Page Object classes |
| Selectors & Locators | references/selectors-locators.md | Best practices for selecting elements in Playwright tests |
| Hooks & World | references/hooks-and-world.md | World class, Before/After, browser lifecycle |
| Tags & Profiles | references/tags-and-profiles.md | Tag expressions, cucumber.js profiles, parallel |
| Reporting | references/reporting.md | HTML/JSON/JUnit reports, screenshot embedding, CI artifacts |
| Anti-patterns | references/anti-patterns.md | Common mistakes and how to fix them |
| Best Practices | references/cucumber-best-practices.md | Scenario design principles: declarative vs imperative, one behavior per scenario |
| Visual Regression | references/visual-regression.md | Visual regression testing, screenshot comparison, baseline management |
| Naming Conventions | references/naming-conventions.md | File and class naming patterns, folder structure, Page Objects, components |
| E2E Testing without Cucumber | references/e2e-testing-without-cucumber.md | BDD/Gherkin user flow testing without Cucumber, classic user flow testing, checkout flow |
| E2E Test Template | references/e2e-test-template.ts | Annotated Playwright E2E test template: page objects, API data setup, explicit waits |
| API Mocking | references/api-mocking.md | Mocking API responses, stubbing endpoints, and testing edge cases |
| API/REST Testing | references/api-rest-testing.md | Testing RESTful APIs, endpoints, and response validation |
| WCAG E2E Testing | references/wcag-e2e-testing.md | Automated WCAG 2.2 accessibility checks in E2E tests with Playwright + axe-core |
These files are only loaded if the agent needs additional context.
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
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.

