Running RStudio Playwright Tests

Run from e2e/rstudio/. Setup, env vars, tags, sandbox, external-server config, and the cross-env / dotenv helpers all live in e2e/rstudio/README.md -- open it when you need any of that.

The four run modes

Mode	Command	Platforms
Installed desktop	npm run test:desktop	macOS, Linux, Windows
Dev desktop build	npm run test:desktop-dev	macOS, Linux, Windows
Installed server	npm run test:server	Linux
Dev server build	npm run test:server-dev	macOS, Linux

Append a test path or Playwright flags after the script name:

npm run test:desktop -- tests/path/to/test.test.ts
npm run test:server-dev -- -g "test name here"

test:desktop-dev prerequisites (from repo root)

1. cmake --build build -- C++ session
2. (cd src/gwt && ant draft) -- GWT transpile (2-5 min; rerun after Java edits)
3. (cd src/node/desktop && npm ci) -- Electron deps

In a secondary worktree, run scripts/bootstrap-worktree.sh instead of steps 1 and 3: when the worktree has no configured build/, the wrapper skips the cmake build and automatically points the launcher at the worktree's build-dev-shim (worktree GWT + main checkout's built session). Step 2 is still on you -- the wrapper only warns when src/gwt/src is newer than the precompiled bootstrap. Do NOT symlink the worktree's build/ at the main checkout's: its conf would silently serve main's GWT.

Tests that exercise doRestart() (e.g. uninstall Posit Assistant) aren't supported in this mode.

Test running protocol

Before the first run in a conversation, pick a mode -- ask the user which of the four they want (use AskUserQuestion if available), filtering out modes unsupported by the host platform. If a build/ directory exists at the repo root, list test:desktop-dev first in the options. Then run the tests directly; don't prompt for approval before kicking off the run. Prefer npm run ... over raw npx playwright test.

After the first run, don't re-ask to re-run the same file in the same mode -- just go. Switching modes (not files) warrants a fresh mode-pick.

Profiling a slow test

When a test passes but is slower than expected, don't guess at the cause -- capture a trace and read per-action timing. Re-run with --trace on, then unzip the trace.zip and pair the before/after events in test.trace by callId to rank actions by duration. The full recipe (with a ready-to-run Node parser) is in the "Profiling a slow test" section of e2e/rstudio/README.md.

Common culprit it surfaces: a value-reading action (e.g. locator.inputValue()) on an element not yet in the DOM blocks on the action timeout -- probe with locator.count() instead and open the editor/popup before reading from it.