@matware/e2e-runner 1.1.1 → 1.3.0

package/skills/e2e-testing/references/troubleshooting.md

@@ -0,0 +1,224 @@
+# Troubleshooting Guide
+
+## Pool Connection Issues
+
+### "Pool not reachable" / Connection refused
+
+**Cause**: Chrome pool (browserless/chrome Docker container) is not running.
+
+**Fix**:
+```bash
+npx e2e-runner pool start
+npx e2e-runner pool status   # verify it's running
+```
+
+Pool management is CLI-only — `pool start` and `pool stop` are not available via MCP.
+
+### "Pool at capacity" / Tests queuing
+
+**Cause**: All Chrome sessions are occupied.
+
+**Fix**: Increase capacity or reduce concurrency:
+```bash
+npx e2e-runner pool stop
+npx e2e-runner pool start --max-sessions 10
+```
+Or reduce test concurrency: `--concurrency 2`
+
+The runner checks `/pressure` before each connection and waits up to 60s for a free slot.
+
+### Docker not running
+
+**Cause**: Docker daemon is not started.
+
+**Fix**: Start Docker Desktop or `sudo systemctl start docker`, then `npx e2e-runner pool start`.
+
+## React / SPA Issues
+
+### React inputs not updating state
+
+**Symptom**: `type` action enters text but React state doesn't change (form validation fails, submit disabled).
+
+**Fix**: Use `type_react` instead of `type` for React controlled inputs:
+```json
+{ "type": "type_react", "selector": "#email", "value": "user@test.com" }
+```
+
+`type_react` uses the native value setter and dispatches `input` + `change` events that React's synthetic event system recognizes.
+
+### SPA navigation not completing
+
+**Symptom**: `goto` hangs or times out on client-side route changes.
+
+**Fix**: Use `navigate` instead of `goto` for SPA route changes:
+```json
+{ "type": "navigate", "value": "/new-page" }
+```
+
+`navigate` uses a 5s race timeout and won't block if `load` doesn't fire (common in SPAs).
+
+### MUI autocomplete not opening
+
+**Symptom**: Clicking or typing in an MUI Autocomplete doesn't open the dropdown.
+
+**Fix**: Use `focus_autocomplete` to properly focus by label text:
+```json
+{ "type": "focus_autocomplete", "text": "Search by name" },
+{ "type": "type_react", "selector": "#autocomplete-input", "value": "search term" },
+{ "type": "click_option", "text": "Desired option" }
+```
+
+## Flaky Tests
+
+### Intermittent failures on dynamic content
+
+**Symptom**: Tests pass sometimes, fail others. Usually timing-related.
+
+**Fixes**:
+1. Add explicit `wait` before assertions:
+   ```json
+   { "type": "wait", "selector": ".data-loaded" },
+   { "type": "assert_text", "text": "Expected content" }
+   ```
+
+2. Use action-level retries for known flaky selectors:
+   ```json
+   { "type": "click", "selector": "#dynamic-btn", "retries": 3 }
+   ```
+
+3. Use test-level retries:
+   ```json
+   { "name": "flaky-test", "retries": 2, "actions": [...] }
+   ```
+
+4. Check the learning system for patterns:
+   ```
+   e2e_learnings("flaky") → identify consistently flaky tests
+   e2e_learnings("selectors") → find unstable selectors
+   ```
+
+### Tests interfering with each other
+
+**Symptom**: Tests pass individually but fail when run together.
+
+**Fix**: Mark tests that share mutable state as `serial`:
+```json
+{ "name": "create-item", "serial": true, "actions": [...] },
+{ "name": "verify-item", "serial": true, "actions": [...] }
+```
+
+## Timeout Issues
+
+### Test timeout (default 60s)
+
+**Fix**: Increase per-test or globally:
+```json
+{ "name": "slow-test", "timeout": 120000, "actions": [...] }
+```
+Or globally: `--test-timeout 120000`
+
+### Action timeout (default 10s)
+
+Each action's `waitForSelector` uses the default timeout. Override per-action:
+```json
+{ "type": "wait", "selector": ".slow-element", "timeout": 30000 }
+```
+Or globally: `--timeout 30000`
+
+## Network Errors
+
+### Tests passing but network requests failing
+
+**Symptom**: Tests pass but `networkSummary` shows failed requests.
+
+**Fix**: Enable strict mode to fail tests with network errors:
+```
+e2e_run({ all: true, failOnNetworkError: true })
+```
+
+Or use `assert_no_network_errors` at specific points:
+```json
+{ "type": "goto", "value": "/api-heavy-page" },
+{ "type": "wait", "selector": ".loaded" },
+{ "type": "assert_no_network_errors" }
+```
+
+### Investigating specific failures
+
+Use network log drill-down:
+```
+e2e_network_logs(runDbId, errorsOnly: true)                    → see all failed requests
+e2e_network_logs(runDbId, urlPattern: "/api/users")             → filter by URL
+e2e_network_logs(runDbId, testName: "create-user", includeBodies: true) → full request/response
+```
+
+## Common Mistakes
+
+### Using `beforeAll` for browser state
+
+`beforeAll` runs on a separate page that closes before tests. Use `beforeEach` for state setup.
+
+### Using `evaluate` for simple assertions
+
+Prefer granular assertion actions over `evaluate` with inline JS:
+```json
+// Bad: verbose, error-prone
+{ "type": "evaluate", "value": "if (!document.querySelector('h1').textContent.includes('Dashboard')) throw 'not found'" }
+
+// Good: clear, auto-waits
+{ "type": "assert_element_text", "selector": "h1", "text": "Dashboard" }
+```
+
+### Forgetting `cwd` in MCP calls
+
+All MCP tools need `cwd` to resolve config files and test directories. Always pass the project root.
+
+### Path-only `assert_url`
+
+When checking paths, use path-only format (starts with `/`):
+```json
+{ "type": "assert_url", "value": "/dashboard" }
+```
+This compares against the pathname only, ignoring the `host.docker.internal` origin.
+
+## Action Type Pre-Validation
+
+All action types are validated at **load time** (before any browser connections). If a test file contains an unknown action type (e.g., a typo like `"clik"`), loading throws immediately with the location:
+
+```
+Unknown action type(s) in auth.json: "clik" in test "login-test"
+```
+
+The `KNOWN_ACTION_TYPES` Set in `src/actions.js` is the single source of truth. Unknown actions also throw at runtime as a safety net.
+
+## Screenshot Hashes
+
+Every screenshot captured during a run is assigned a short hash (`ss:a3f2b1c9`) — the first 8 hex chars of the SHA-256 of its file path. Hashes are deterministic and computed identically on the server (Node `crypto`) and in the browser (Web Crypto API).
+
+**Flow**: screenshot saved on disk → `saveRun()` registers hash in SQLite `screenshot_hashes` table → dashboard shows `[ss:XXXXXXXX]` badge (click to copy) → user pastes hash in Claude Code → `e2e_screenshot` MCP tool looks up hash, reads file, returns the image.
+
+- Hashes are registered inside the `saveRun()` transaction (covers action, error, verification, and baseline screenshots)
+- The `ss:` prefix is optional when calling `e2e_screenshot` — stripped during lookup
+- Dashboard computes hashes client-side (Web Crypto) for the Live view (before `persistRun()` writes to DB)
+- Run detail API (`/api/db/runs/:id`) includes `screenshotHashes` map per test result
+- Dashboard endpoint `/api/screenshot-hash/:hash` serves the image by hash
+- Dashboard Screenshots view has a **search bar** — type a hash to find and display the screenshot
+
+## Web Dashboard
+
+**`src/dashboard.js`** — HTTP server, REST API, WebSocket broadcast, pool polling.
+**`templates/dashboard.html`** — SPA, dark theme, vanilla JS, safe DOM (textContent + createEl helper).
+
+**Features:**
+- Live test execution with WebSocket updates
+- Run history with inline detail expansion
+- Screenshots gallery with hash badges and hash search
+- Network request logs with clickable expandable rows (full request/response detail)
+- Pool status monitoring
+- Multi-project support via project selector
+- Variables tab with masked values, inline edit, add, and delete
+
+**CLI:** `e2e-runner dashboard [--port 8484]`
+**MCP tools:** `e2e_dashboard_start`, `e2e_dashboard_stop`
+
+Config defaults: `dashboardPort: 8484`, `maxHistoryRuns: 100`

package/skills/e2e-testing/references/variables.md

@@ -0,0 +1,41 @@
+# Variables Reference
+
+Variables replace hardcoded sensitive values (JWT tokens, user IDs, API keys, etc.) in test JSON. Stored in SQLite (`~/.e2e-runner/dashboard.db`), scoped per project and per suite, editable from the dashboard UI.
+
+## Syntax
+
+```
+{{var.TOKEN}}        → resolves from DB (suite scope → project scope)
+{{env.MY_VAR}}       → resolves from process.env
+{{param}}            → existing module param substitution (unchanged)
+```
+
+**Resolution priority:** suite vars > project vars > error if not found.
+
+## Usage in Test JSON
+
+```json
+{ "$use": "auth-jwt", "params": { "token": "{{var.JWT_TOKEN}}", "orgId": "{{var.ORG_ID}}" } }
+{ "type": "goto", "value": "/users/{{var.USER_ID}}/profile" }
+{ "type": "gql", "value": "{ user(id: \"{{var.USER_ID}}\") { name } }" }
+```
+
+## MCP Tool (`e2e_vars`)
+
+```
+e2e_vars({ action: "set", key: "TOKEN", value: "abc123", scope: "project" })
+e2e_vars({ action: "set", key: "TOKEN", value: "xyz789", scope: "auth" })  // suite-specific override
+e2e_vars({ action: "list" })
+e2e_vars({ action: "get", key: "TOKEN" })
+e2e_vars({ action: "delete", key: "TOKEN", scope: "project" })
+```
+
+## Dashboard UI
+
+Variables tab shows all variables grouped by scope. Values are masked by default (click to reveal). Inline edit, add new, and delete are supported.
+
+## REST API
+
+- `GET /api/db/projects/:id/variables` — list all vars for project
+- `PUT /api/db/projects/:id/variables` — set a variable `{ scope, key, value }`
+- `DELETE /api/db/projects/:id/variables/:scope/:key` — delete a variable

package/skills/e2e-testing/references/visual-verification.md

@@ -0,0 +1,89 @@
+# Visual Verification Reference
+
+Tests can include an `expect` field for AI-powered visual verification. No API key required — Claude Code itself does the visual judgment.
+
+## Expect Field Formats
+
+### String form — free-form description
+```json
+{
+  "name": "dashboard-loads",
+  "expect": "Should show the data table with at least 3 rows, no error messages, and the sidebar with navigation links",
+  "actions": [
+    { "type": "goto", "value": "/dashboard" },
+    { "type": "wait", "selector": ".data-table" }
+  ]
+}
+```
+
+### Array form — per-criterion checklist (each evaluated independently as PASS/FAIL)
+```json
+{
+  "name": "dashboard-loads",
+  "expect": [
+    "Data table visible with at least 3 rows",
+    "No error messages or red banners",
+    "Sidebar shows navigation links"
+  ],
+  "actions": [
+    { "type": "goto", "value": "/dashboard" },
+    { "type": "wait", "selector": ".data-table" }
+  ]
+}
+```
+
+## Double Screenshot (Before/After)
+
+When `expect` is present, the runner captures TWO screenshots:
+1. **Baseline** (`baseline-{name}-{timestamp}.png`) — captured BEFORE test actions run (after `beforeEach` hooks)
+2. **Verification** (`verify-{name}-{timestamp}.png`) — captured AFTER all actions complete
+
+Both hashes are registered in SQLite and returned in the MCP response for before/after comparison.
+
+## Verification Strictness
+
+Controls how strictly Claude Code evaluates visual verification. Set via:
+- Config: `verificationStrictness: 'moderate'`
+- CLI: `--verification-strictness strict`
+- Env: `VERIFICATION_STRICTNESS=strict`
+- MCP: `verificationStrictness: 'strict'` in `e2e_run` args
+
+| Level | Behavior |
+|-------|----------|
+| **`strict`** | No ambiguity allowed. If any criterion is unclear, not fully visible, or doubtful → FAIL. |
+| **`moderate`** (default) | Reasonable judgment. Minor cosmetic differences acceptable, functional mismatches → FAIL. |
+| **`lenient`** | Only fail on clear, obvious contradictions. |
+
+## MCP Response Format
+
+The `e2e_run` response includes a `verifications` array:
+```json
+{
+  "verifications": [
+    {
+      "name": "dashboard-loads",
+      "expect": ["Data table visible...", "No error messages..."],
+      "success": true,
+      "screenshotHash": "ss:a3f2b1c9",
+      "baselineScreenshotHash": "ss:b4e1c2d8",
+      "isChecklist": true
+    }
+  ],
+  "verificationInstructions": "Verification strictness: MODERATE — ..."
+}
+```
+
+## Verdict Format
+
+After calling `e2e_screenshot` for each hash (after + baseline), Claude Code reports a structured verdict:
+
+```
+TEST: dashboard-loads
+VERDICT: PASS
+STATE CHANGE: Page loaded from blank to populated dashboard
+CRITERIA:
+  - "Data table visible with at least 3 rows": PASS
+  - "No error messages or red banners": PASS
+  - "Sidebar shows navigation links": PASS
+REASON: All criteria met, dashboard fully loaded with expected content
+```