b60638f0a3
Community Skills (32): - jat: jat-start, jat-verify, jat-complete - pi-mono: codex-cli, codex-5.3-prompting, interactive-shell - picoclaw: github, weather, tmux, summarize, skill-creator - dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.) - dexter: dcf valuation skill Agents (23): - pi-mono subagents: scout, planner, reviewer, worker - toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.) System Prompts (91): - Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.) - OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools) - Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli) - xAI: 5 Grok prompts - Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.) Hooks (9): - JAT hooks for session management, signal tracking, activity logging Prompts (6): - pi-mono templates for PR review, issue analysis, changelog audit Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell, craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus, zed, clawdbot, OS-Copilot, and more
137 lines
4.3 KiB
Markdown
137 lines
4.3 KiB
Markdown
---
|
|
name: dyad:debug-with-playwright
|
|
description: Debug E2E tests by taking screenshots at key points to visually inspect application state.
|
|
---
|
|
|
|
# Debug with Playwright Screenshots
|
|
|
|
Debug E2E tests by taking screenshots at key points to visually inspect application state.
|
|
|
|
## Arguments
|
|
|
|
- `$ARGUMENTS`: (Optional) Specific E2E test file to debug (e.g., `main.spec.ts` or `e2e-tests/main.spec.ts`). If not provided, will ask the user which test to debug.
|
|
|
|
## Background
|
|
|
|
Dyad uses Electron + Playwright for E2E tests. Because Playwright's built-in `screenshot: "on"` option does NOT work with Electron (see https://github.com/microsoft/playwright/issues/8208), you must take screenshots manually via `page.screenshot()`.
|
|
|
|
The test fixtures in `e2e-tests/helpers/fixtures.ts` already auto-capture a screenshot on test failure and attach it to the test report. But for debugging, you often need screenshots at specific points during test execution.
|
|
|
|
## Instructions
|
|
|
|
1. **Identify the test to debug:**
|
|
|
|
If `$ARGUMENTS` is empty, ask the user which test file they want to debug.
|
|
- If provided without the `e2e-tests/` prefix, add it
|
|
- If provided without the `.spec.ts` suffix, add it
|
|
|
|
2. **Read the test file:**
|
|
|
|
Read the test file to understand what it does and where it might be failing.
|
|
|
|
3. **Add debug screenshots to the test:**
|
|
|
|
Add `page.screenshot()` calls at key points in the test to capture visual state. Access the page from the `po` fixture:
|
|
|
|
```typescript
|
|
// Get the page from the electronApp fixture
|
|
const page = await electronApp.firstWindow();
|
|
|
|
// Or if you only have `po`, access the page directly:
|
|
// po is a PageObject which has a `page` property
|
|
```
|
|
|
|
**Screenshot patterns for debugging:**
|
|
|
|
```typescript
|
|
import * as fs from "fs";
|
|
import * as path from "path";
|
|
|
|
// Create a debug screenshots directory
|
|
const debugDir = path.join(__dirname, "debug-screenshots");
|
|
if (!fs.existsSync(debugDir)) {
|
|
fs.mkdirSync(debugDir, { recursive: true });
|
|
}
|
|
|
|
// Take a full-page screenshot
|
|
await page.screenshot({
|
|
path: path.join(debugDir, "01-before-action.png"),
|
|
});
|
|
|
|
// Take a screenshot of a specific element
|
|
const element = page.locator('[data-testid="chat-input"]');
|
|
await element.screenshot({
|
|
path: path.join(debugDir, "02-chat-input.png"),
|
|
});
|
|
|
|
// Take a screenshot after some action
|
|
await po.sendPrompt("hi");
|
|
await page.screenshot({
|
|
path: path.join(debugDir, "03-after-send.png"),
|
|
});
|
|
```
|
|
|
|
**Important:** The test fixture signature provides `{ electronApp, po }`. To get the page:
|
|
- Use `await electronApp.firstWindow()` to get the page
|
|
- Or use `po.page` if PageObject exposes it
|
|
|
|
Add screenshots before and after the failing step to understand what the UI looks like at that point.
|
|
|
|
4. **Build the app (if needed):**
|
|
|
|
E2E tests run against the built binary. If you made any application code changes:
|
|
|
|
```
|
|
npm run build
|
|
```
|
|
|
|
If you only changed test files, you can skip this step.
|
|
|
|
5. **Run the test:**
|
|
|
|
```
|
|
PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_HTML_OPEN=never npm run e2e -- e2e-tests/<testfile>.spec.ts
|
|
```
|
|
|
|
6. **View the screenshots:**
|
|
|
|
Use the Read tool to view the captured PNG screenshots. Claude Code can read and display images directly:
|
|
|
|
```
|
|
Read the PNG files in e2e-tests/debug-screenshots/
|
|
```
|
|
|
|
Analyze the screenshots to understand:
|
|
- Is the expected UI element visible?
|
|
- Is there an error dialog or unexpected state?
|
|
- Is a loading spinner still showing?
|
|
- Is the layout correct?
|
|
|
|
7. **Check the Playwright trace (for additional context):**
|
|
|
|
The Playwright config has `trace: "retain-on-failure"`. If the test failed, a trace file will be in `test-results/`. You can reference this for additional debugging context.
|
|
|
|
8. **Iterate:**
|
|
|
|
Based on what you see in the screenshots:
|
|
- Add more targeted screenshots if needed
|
|
- Fix the issue in the test or application code
|
|
- Re-run to verify
|
|
|
|
9. **Clean up:**
|
|
|
|
After debugging is complete, remove the debug screenshots and any temporary screenshot code you added to the test:
|
|
|
|
```
|
|
rm -rf e2e-tests/debug-screenshots/
|
|
```
|
|
|
|
Remove any `page.screenshot()` calls you added for debugging purposes.
|
|
|
|
10. **Report findings:**
|
|
|
|
Tell the user:
|
|
- What the screenshots revealed about the test failure
|
|
- What fix was applied (if any)
|
|
- Whether the test now passes
|