agentleFS
forcedotcomforcedotcom/salesforcedx-vscode/.claude/skills/playwright-e2e/SKILL.md

playwright-e2e

Skill1k starsChanged 25 days agoBSD-3-ClauseView on GitHub

writing, running, and debugging Playwright tests; creating and recreating scratch orgs (Dreamhouse, minimal, non-tracking); working with their output from github actions

  • Reads credentials
  • Deletes or force-pushes

13 other projects use a version of this.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about forcedotcom/salesforcedx-vscode

The biggest 5 of 52 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 52

Talked about on GitHub and Stack Overflow (52 times).

On GitHub · 50

45 more on GitHub

Used with

Projects with it also use security-review.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • SentrySkill

    security-review

    Finds exploitable application security vulnerabilities in code changes. Use for Warden security scans, appsec review, OWASP-style checks, authentication or authorization bugs, injection, XSS, SSRF, path traversal, secrets, unsafe crypto, webhook verification, open redirects, or sensitive data exposure.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 4 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Default: process.env.E2E_FROM_VSIX === '1' — set in CI to enable without code changes.

    line 35
  2. Distinctive:

    Pattern: Run command, capture artifacts, reload window to flush TelemetryFile buffer (fires deactivationEvent), then assert event/span …

    line 72
  3. Distinctive:

    If you aren't sure if orgs are set up locally,

    line 76
  4. Very specific:

    Look for the required org aliases (e.g., minimalTestOrg, nonTrackingTestOrg, orgBrowserDreamhouseTestOrg).

    line 82
  5. Very specific:

    Pro tip: Use sf org list --json | jq '.result.scratchOrgs[] | select(.alias) | .alias' to list only scratch org aliases.

    line 84
  6. Very specific:

    When running Playwright tests (pnpm … test:web, test:desktop, etc.), never block >30s.

    line 88
  7. Distinctive:

    write the file on disk (desktop fs / web memfs), or

    line 103
  8. Distinctive:

    When testing native Test Controller surfaces (Test Explorer, Test Results panel):

    line 123
  9. Very specific:

    Test Results panel: Wait for tab visibility, then assert Pass Rate text (e.g., getByText(/Pass Rate/i))

    line 125
  10. Very specific:

    Locators: Use TEST_RESULTS_TAB = 'a.action-label[aria-label="Test Results"]' to target panel tab reliably

    line 127

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “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

Playwright E2E Tests

Guidelines for writing and iterating on Playwright tests for VS Code extensions.

Required Reading

Read ALL before responding:

  • references/coding-playwright-tests.md - Writing tests; post-setup flow recording and explicit screenshot boundaries
  • references/local-setup.md - Scratch org setup (Dreamhouse, minimal, non-tracking)
  • references/iterating-playwright-tests.md - Iterating on tests ("Things to ignore" for failure analysis)
  • references/analyze-e2e.md - Analyzing E2E test results and attached videos from CI

Use playwright-vscode-ext

Shared code (helpers, locators, configuration) for tests.

Desktop workspace shapes (pick one per test):

  • No folder open — fixture opens a Salesforce project, then call prepareNoFolderOpenForPaletteTests(page) (runs Workspaces: Close Workspace + workbench wait). Or use closeWorkspaceToEmptyWindow if UI is already prepared.
  • Folder open, no sfdx-project.json — createDesktopTest({ emptyWorkspace: true }); workspace path comes from createEmptyTestWorkspace() (also exported from the package).
  • Default org in workspace — pass orgAlias: '…' (e.g. MINIMAL_ORG_ALIAS / NON_TRACKING_ORG_ALIAS / DREAMHOUSE_ORG_ALIAS) so .sfdx/config.json gets target-org. Omit orgAlias or use undefined for no config.json (no org).
  • Multi-package directory, no org — multiPackageNoOrgDesktopTest (extend noOrgDesktopTest); creates a temp workspace with sfdx-project.json listing multiple packageDirectories (force-app, extra-pkg). Use multiPackageNoOrgTest from fixtures/index.ts in test files.

VSIX mode (useVsix option):

  • createDesktopTest({ useVsix: true }) — installs built VSIXs into a hash-keyed cache dir (.vscode-test/ext-<hash>/) and launches VS Code with --extensions-dir instead of --extensionDevelopmentPath. Exercises real shipping artifact (bundled dist/, .vscodeignore, packageUpdates).
  • Installs requested local VSIX dirs in extensionDependencies order (from each local package.json), so local dependency VSIXs install before dependents.
  • Default: process.env.E2E_FROM_VSIX === '1' — set in CI to enable without code changes.
  • Requires vscode:package to have run first (produces .vsix in package dir). test:desktop depends on vscode:package for this reason.
  • Idempotent across parallel workers: atomic rename; second worker skips if cache exists.

Code Builder container mode (createContainerConfig, createContainerTest):

  • createContainerConfig({ testDir: '…' }) — config for driving tests against a running Code Builder container. Container lifecycle (run, extension swap, health checks) managed by orchestrator/CI, not Playwright. Tests drive a browser-client to the container URL (like web mode) while the workbench runs the desktop extension build. Use env CODE_BUILDER_URL (defaults to http://localhost:8123).
  • createContainerTest() — fixture that navigates a plain Chromium page to the container workbench and waits for readiness. Specs reuse existing page objects (commands, helpers, locators) unchanged.
  • Seeding: seedWorkspace (exported from the toolkit) handles post-boot writes (coder.json path + workspace-trust setting). Works with fixture projects mounted into the container (e.g. test/playwright/fixtures/container-workspace/). Call after workbench readiness, before extension swap/restart.

Span files (when debugging traces)

Available local + CI/GHA.

  • Output: ~/.sf/vscode-spans/ — web-*.jsonl (test:web), node-*.jsonl (test:desktop)
  • Auto-enabled (no manual enable needed)
  • CI runs: copied into package test-results/spans/ artifacts (see workflow upload/download in references/analyze-e2e.md)
  • Latest: ls -lt ~/.sf/vscode-spans/
  • Clear before run for fresh output: rm -rf ~/.sf/vscode-spans/
  • Format: JSONL; parse each line with JSON.parse
  • Fields: name, traceId, spanId, parentSpanId, durationMs, status, startTime, attributes

See .claude/skills/span-file-export/SKILL.md for enable/OTLP vs file.

Telemetry inspection (diagnostic tests)

Desktop tests can inspect both telemetry pipelines on-disk for diagnostic/integration testing:

  1. O11y spans — produced by services Effect pipeline; written to ~/.sf/vscode-spans/*.jsonl (auto-enabled)
  2. AppInsights events — produced by class-based TelemetryFile reporter when localTelemetryLogging is enabled; written to {workspace}/salesforcedx-vscode-core-telemetry.json (AppInsights shape, real client inert in dev/test)

Fixture setup: Enable both pipelines by passing additionalExtensionDirs: ['salesforcedx-vscode-core'] (for core extension + TelemetryFile reporter) and userSettings: { 'telemetry.telemetryLevel': 'all', 'salesforcedx-vscode-core.advanced.localTelemetryLogging': 'true' } to createDesktopTest. Launch against a real scratch org (e.g., orgAlias: MINIMAL_ORG_ALIAS) so org-identity attributes populate in both pipelines.

Reading artifacts:

  • Spans: parse ~/.sf/vscode-spans/*.jsonl line-by-line with JSON.parse
  • AppInsights events: file contains comma-separated pretty JSON objects; wrap in [] and strip trailing comma to parse: JSON.parse([${raw.trim().replace(/,\s*$/, '')}])

Pattern: Run command, capture artifacts, reload window to flush TelemetryFile buffer (fires deactivationEvent), then assert event/span presence + attributes. See packages/salesforcedx-vscode-lightning/test/playwright/specs/telemetryOutput.desktop.spec.ts for example.

Checking for Scratch Orgs

If you aren't sure if orgs are set up locally,

sf org list

Look for the required org aliases (e.g., minimalTestOrg, nonTrackingTestOrg, orgBrowserDreamhouseTestOrg). If missing, create them using the appropriate setup commands from references/local-setup.md.

Pro tip: Use sf org list --json | jq '.result.scratchOrgs[] | select(.alias) | .alias' to list only scratch org aliases.

Running tests (AI behavior)

When running Playwright tests (pnpm … test:web, test:desktop, etc.), never block >30s. Use is_background: true so tests run while the AI continues. Check terminal output or output_file later.

Apex OAS E2E Tests

Playwright desktop tests live in packages/salesforcedx-vscode-apex-oas/test/playwright/specs/ with dedicated CI workflow .github/workflows/apexOasE2E.yml (macOS + ubuntu, desktop only). Specs share one MINIMAL_ORG_ALIAS scratch org and are serialized via workers: 1 in playwright.config.desktop.ts. Tests that deploy ESR metadata requiring API >=66 call setWorkspaceApiVersion() to bump the fixture's default sourceApiVersion (64.0 → 66.0). Specs that click modal-dialog buttons require window.dialogStyle: custom in the fixture's userSettings. The OAS REST generation path requires an LLM service registered with the VS Code service provider — supplied at runtime by A4V (salesforce.salesforcedx-einstein-gpt), which is no longer a declared extensionDependency. The AuraEnabled path needs only an active org. Specs exercising REST generation install A4V via the desktop fixture's pre-launch step; obtaining the LLM service is fail-fast, so waitForA4VAndOasCommands calls waitForExtensionsActivated to ensure the provider has registered its command before generation runs.

A4V LLM rate limit = skip, not fail (pre-migration): the shared Core model exhausting its monthly quota is an infra outage, not a product bug — it can hit any spec that triggers a generation LLM call (all composed/decomposed/context-menu specs), not just manual-merge. The extension surfaces it as a real error notification (/monthly rate limit/, from the llm_monthly_rate_limit i18n message) instead of the old generic "LLM did not return any content", so specs detect it straight from the UI — no span-file scan. Wrap the generation success signal with assertGenerationOrSkipOnRateLimit(test, page, success) (oasHelpers): success is the success assertion (expect(tab).toBeVisible() or waitForEsrFile(...)); it races the rate-limit notification and test.skips if that wins, else resolves/rethrows. The eligibility-failure specs (ineligibleClass, mixedFrameworksClass, restResourceNoHttpMethod) fail before any LLM call and need no guard.

Don't use the clipboard to set editor content

navigator.clipboard.writeText + Paste is a shared global resource — desktop Electron clipboard is the system OS clipboard (electronjs.org/docs/latest/api/clipboard), so parallel workers (fullyParallel: true) race: worker B's write between A's write and A's Paste makes A paste B's text. Flaky, hard to diagnose.

Set content directly instead:

  • type via page.keyboard.type(text) after focusMonacoInput + Select All + Delete (editor selection), or
  • write the file on disk (desktop fs / web memfs), or
  • set the editor model value through a VS Code command.

Note: "keyboard shortcut can miss on web" comments refer to shortcut keystrokes (Cmd+A/Cmd+V) not landing — fix is command-palette Select All/Paste, not clipboard. Clipboard ≠ required for that.

Running Full E2E Test Suite

See references/full-suite-execution.md for complete guide on running all E2E tests locally across all 9 packages in correct dependency order with failure analysis.

Disable/reenable other E2E when iterating

To run only your new test in CI while iterating:

  1. Disable other workflows — add your branch to branches-ignore in .github/workflows/*.yml that have push: branches-ignore: [main, develop] (e.g. testCommitExceptMain.yml, coreE2E.yml, orgBrowserE2E.yml, lwcPlaywrightE2E.yml, etc.)
  2. Filter target workflow — add --grep "Your Test Title" to the test run command in the workflow you care about
  3. Optional — skip org setup steps not needed for your test (e.g. minimal/non-tracking orgs)
  4. Restore — remove branch from branches-ignore, remove --grep, uncomment skipped steps

Test Controller Native Surfaces

When testing native Test Controller surfaces (Test Explorer, Test Results panel):

  • Test Results panel: Wait for tab visibility, then assert Pass Rate text (e.g., getByText(/Pass Rate/i))
  • Tree items: Assert aria-label contains expected decoration (e.g., toHaveAttribute('aria-label', /Passed/i) for completed tests)
  • Locators: Use TEST_RESULTS_TAB = 'a.action-label[aria-label="Test Results"]' to target panel tab reliably
  • Test run completion: Call verifyNoTestRunInProgress (playwright-vscode-ext) after every Apex test run — sidebar, code lens, palette, suite, debug. Results/tree decorations/Ended … sentinel appear while TestRun still open; absence of 'Test: Cancel Test Run' command proves run ended. Sidebar (Test Explorer) runs: call before dismissing/clicking the success toast—that would end a run blocked on it, masking regressions. Palette/code lens runs have no TestRun tied to the toast, so order vs. toast doesn't matter.

Reliable Assertions for Async Operations

For desktop-only tests, prefer durable success signals over flaky UI assertions:

  • Avoid: vscode.window.showInformationMessage toasts auto-dismiss in seconds; notification-list-item assertions are racy
  • Prefer: Poll on-disk artifacts (e.g., generated files) with exponential backoff. Example: waitForEsrFile checks fs.access repeatedly until artifact appears or timeout.
  • Pattern: Create a helper that polls fs.access or fs.stat with Date.now() < deadline loop; throw on timeout with clear error message

References

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.