browser-e2e-tests

Author Playwright end-to-end tests for the Composer app using data-testid selectors and page objects.

518|49|Updated Apr 7, 2021
One-click install
npx skills add https://github.com/dxos/dxos --skill browser-e2e-tests
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: browser-e2e-tests
Source: https://github.com/dxos/dxos/tree/main/.agents/skills/browser-e2e-tests
Command: npx skills add https://github.com/dxos/dxos --skill browser-e2e-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Writing browser end-to-end tests for the Composer app often fails because selectors target translated labels or ambiguous role names, producing flaky tests that break on copy changes. This Skill enforces a stable, testid-first testing discipline with page objects so specs stay readable and resilient.

Core Features & Use Cases

  • Testid-first selector strategy: Mandates data-testid targeting (never labels, text, or role names) and explains how to add testids to components, including properties.testId for menu and toolbar actions.
  • Page-object architecture: Directs all interactions through AppManager and per-plugin helpers under plugins/ so specs express intent rather than inline selectors.
  • Stability and execution rules: Covers running with DX_PWA=false moon run composer-app:e2e, browser selection, throttled cold-start harness options, and web-first assertions instead of waitForTimeout.
  • Use Case: When adding a spec for the Inbox plugin, create an Inbox page object under plugins/, add inbox.message.reply testids to the components, and write the spec driving the real UI via createSpace and createObject.

Quick Start

Write a new Playwright spec for the Composer Inbox plugin that selects a thread and verifies the companion opens, using data-testid selectors and a page-object helper.

Frequently Asked Questions about browser-e2e-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Playwright e2e tests for the Composer app?▼

Create a *.spec.ts file under packages/apps/composer-app/src/playwright, use the AppManager page object to init and create spaces, and target elements exclusively with getByTestId. Run tests with DX_PWA=false moon run composer-app:e2e.

How do I select elements in Playwright tests without using labels?▼

Use page.getByTestId with a dot-namespaced data-testid like 'inbox.message.reply'. If the element lacks a testid, add one to the component; for menu or toolbar actions, set properties.testId on the action spec.

Why do Playwright tests fail when targeting button labels or text?▼

Labels and visible text come from translations.ts and change with copy or i18n updates, breaking selectors. Role names are also ambiguous when multiple controls share a name, so data-testid is the only stable selector.

Can I use page.waitForTimeout in Playwright e2e specs?▼

No, fixed timeouts are prohibited. Use auto-retrying web-first assertions like expect(locator).toBeVisible(), locator.waitFor(), or assert on framework state such as aria-selected for stable waiting behavior.

How do I run Composer e2e tests on a specific browser?▼

Set PLAYWRIGHT_BROWSER=chromium, firefox, webkit, or all when running the e2e target. Many tests are chromium-only via test.skip, and the throttled cold-start harness with DX_HARNESS_THROTTLED=1 also requires chromium.

When should I use a test bridge instead of driving the real UI?▼

Use a documented, dev/e2e-gated test bridge only when a flow cannot be driven from the UI, such as OAuth login. Never use live credentials or real third-party network calls; mock external HTTP instead.