mnashed13/playwright-testing-framework

Purpose and Entry Points

This is a Node.js TypeScript automated-testing framework combining Cucumber BDD scenarios with Playwright. It has separate UI/browser and API test suites. Main execution is through npm scripts in package.json, with Cucumber profiles/configuration in cucumber.cjs and browser settings in playwright.config.ts.

UI BDD Test Pipeline

UI scenarios begin as Gherkin features, are bound to Cucumber step definitions, then drive browser interactions through page objects:

• src/features/login.feature

• src/steps/login.steps.ts

• src/pages/login.page.ts

The UI suite is invoked by npm test; Cucumber is the scenario orchestrator and Playwright supplies browser automation and assertions.

UI Runtime Lifecycle and State Boundary

A custom Cucumber World holds per-scenario Playwright state, while hooks establish and dispose browser/page resources around scenarios. Environment handling is isolated from feature and page code:

• src/support/world.ts

• src/support/hooks.ts

• src/support/env.ts

This separates declarative scenarios and step logic from browser lifecycle, credentials, runtime browser selection, and environment-dependent values.

Page-Object Automation Layer

Page objects encapsulate navigation, locators, and UI operations; steps should express business actions rather than selectors. BasePage provides shared browser-page behavior, and LoginPage specializes login interactions:

• src/pages/base.page.ts

• src/pages/login.page.ts

• src/test-data/test-data.ts

Test data is kept outside scenario and page control flow, reducing direct dependence on credentials or fixed UI inputs.

API BDD Test Pipeline

API tests are a parallel Cucumber suite with no browser-page dependency. Features select endpoint behaviors, step definitions issue requests via a shared client, and the API World retains scenario request/response context:

• api-tests/features/echo-api.feature

• api-tests/steps/echo-api.steps.ts

• api-tests/support/api-client.ts

The user endpoint coverage follows the same pattern in api-tests/features/user-api.feature and api-tests/steps/users-api.steps.ts. API execution is exposed through npm run test:api, smoke filtering, and Echo-specific scripts.

API Diagnostics and Reporting

The API client boundary centralizes external HTTP communication. Supporting code formats reproducible curl representations and generates test reports:

• api-tests/support/world.ts

• api-tests/support/curl-formatter.ts

• api-tests/support/report-generator.ts

Generated artifacts include Cucumber HTML/JSON under reports/ and API report generation entry code in api-tests/generate-report.ts. Browser-oriented output is published under playwright-report/.

Build, CI, and Release Boundaries

Source TypeScript is compiled into committed/generated JavaScript under dist/, which mirrors the UI suite structure:

• tsconfig.json

• dist/steps/login.steps.js

• dist/support/world.js

CI is represented across GitHub Actions, Buildkite, and Azure pipeline definitions. GitHub Actions runs API tests and semantic-release; release flow treats passing tests and report artifacts as a release gate:

• .github/workflows/api-tests.yml

• .github/workflows/semantic-release.yml

• .buildkite/pipeline.yml

External dependencies/material runtimes are Node.js, Cucumber.js, Playwright, target web applications for UI testing, and target HTTP services for API testing.