rstudio 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)
cmake --build build-- C++ session(cd src/gwt && ant draft)-- GWT transpile (2-5 min; rerun after Java edits)(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.