Build a Cross-Browser Learning Platform Test Suite

1. Multi-browser project setup and first tests

Scenario: you are building a real, local automated test suite for a small demo web app (any simple static site or local dev server you control, including a few pages of this very platform if you run it locally) — entirely on your own machine. Initialize a Playwright + TypeScript project (npm init playwright@latest), configure playwright.config.ts to run against at least Chromium and Firefox, and write a first smoke test that navigates to a page and asserts a heading is visible using a role-based locator.

• npx playwright test runs the suite against at least two real, distinct browser engines
• The first test uses a role-based locator (getByRole) and a web-first assertion, not a fixed sleep
• playwright.config.ts defines at least two named projects, one per browser engine

2. Reliable locators and multi-page navigation

Add tests covering at least two more real user flows across multiple pages of your demo app — using only role-based or accessible locators, Playwright's auto-waiting, and web-first assertions (expect(locator).toBeVisible(), .toHaveText(), etc.). Include at least one test verifying an error or edge-case state (an invalid form submission, a not-found page), not just the happy path.

• At least 2 additional tests cover distinct, multi-page user flows
• Every locator is role-based or otherwise accessible-attribute-based -- no brittle CSS-position or XPath-index selectors
• At least one test verifies an error or edge-case state, not only a success path

3. Fixtures, authentication state, and page objects

Build a custom fixture that establishes and reuses authentication state (a real storageState setup project, or a mocked login flow appropriate to your demo app) so authenticated tests don't each re-perform login from scratch. Introduce at least two page objects for the most-used pages, and refactor at least 3 existing tests to use them instead of inline locators.

• A dedicated setup project or fixture establishes authentication state once and reuses it via storageState
• At least 2 page objects exist, each wrapping one page's locators and actions behind a small, meaningful API
• At least 3 tests use the page objects instead of constructing locators inline

4. Test data, parallel execution, and retry/timeout policy

Add a small test-data builder function (with sensible defaults and an overridable partial input) for any test data your suite creates. Configure fullyParallel: true and a deliberate, small retry count (1-2) with a documented, comfortable timeout margin above your app's normal response times. Confirm the full suite still passes running in parallel, with genuinely isolated tests (no shared, hardcoded test data).

• At least one test-data builder function exists and is used by at least 2 tests with different overrides
• playwright.config.ts sets fullyParallel: true and a small, documented retry count
• The full suite passes when run in parallel, with no test depending on another test's data or execution order

5. Diagnostics and CI reporting

Intentionally break one test (change an assertion to a wrong expected value), run the suite, and use the trace viewer (npx playwright show-trace) to diagnose exactly what happened -- then fix the test. Add a GitHub Actions workflow (.github/workflows/playwright.yml) that installs Playwright's browsers, runs the suite, and uploads the HTML report as an artifact on failure.

• A real trace was captured for a genuinely failing test and inspected in the trace viewer to identify the cause
• The suite is restored to a fully passing state after the diagnosis
• A CI workflow file exists that installs browsers, runs the suite, and uploads the report artifact on failure