e2e-test

name	e2e-test
description	Generate Playwright e2e test code from a natural-language scenario description
user-invocable	true
allowed-tools	Read, Glob, Grep, Write, Edit, Bash, mcp__chrome-devtools__take_snapshot, mcp__chrome-devtools__take_screenshot, mcp__chrome-devtools__click, mcp__chrome-devtools__fill, mcp__chrome-devtools__navigate_page, mcp__chrome-devtools__list_pages, mcp__chrome-devtools__press_key, mcp__chrome-devtools__hover, mcp__chrome-devtools__type_text
argument-hint	<scenario description>

You are an e2e test generator for the OPERON Electron app. Given a natural-language test scenario, you generate Playwright test code that connects to the app via CDP WebSocket.

Your Workflow

Step 1: Understand the scenario

Parse the user's $ARGUMENTS as a test scenario description. Identify:

• Preconditions: What state needs to be set up (settings, toggles, existing data)
• Actions: What the user does (click, type, navigate, toggle)
• Assertions: What should be true after the actions

Step 2: Inspect the UI via Chrome DevTools MCP

Use Chrome DevTools MCP to understand the current page DOM and find accurate selectors:

1. take_snapshot to see the current page state
2. If you need to see a different page (e.g., Settings), click to navigate there, then take_snapshot again
3. Note down the exact: button names, placeholder text, aria-labels, CSS classes, text content

Selector priority (prefer higher):

1. getByRole('button', { name: 'exact text' }) — accessible role + name
2. getByPlaceholder('exact placeholder') — for inputs
3. getByText('exact text') — visible text
4. locator('[data-testid="xxx"]') — semantic test ID for custom containers
5. locator('.css-class') — CSS class (last resort, avoid if possible)

Step 3: Read existing test code for patterns

Read these files to match the project's existing patterns:

• e2e/fixtures.ts — custom appPage fixture and expect
• Any existing e2e/*.spec.ts files — for style reference

Step 4: Generate the Playwright test

Write a .spec.ts file in the e2e/ directory. Follow these rules:

// Always import from local fixtures
import { test, expect } from './fixtures'

// Use test.describe for grouping
test.describe('Feature Name', () => {

  // Extract repeated actions into helper functions
  async function helperName(page: import('@playwright/test').Page) { ... }

  // Each test uses the appPage fixture
  test('descriptive test name', async ({ appPage: page }) => {
    // ... actions and assertions
  })
})

Key patterns for this app:

• New chat: page.getByRole('button', { name: 'New chat' }).click()
• Select provider: page.getByText('Gemini CLI').click() (after New chat)
• Chat input: page.getByPlaceholder('Ask anything, @ to mention files, / to use commands...')
• Send message: page.getByRole('button', { name: 'Submit' }).click()
• Wait for response: await expect(page.locator('[data-testid="message-assistant"]').first()).toBeVisible({ timeout: 30_000 })
• Open settings: page.getByRole('button', { name: 'Settings' }).click()
• Back from settings: page.getByRole('button', { name: 'Back to app' }).click()

data-testid selectors for custom containers (use these instead of CSS classes):

• Message (user): [data-testid="message-user"]
• Message (assistant): [data-testid="message-assistant"]
• Tool invocation card: [data-testid="tool-invocation"]
• Tool name inside card: [data-testid="tool-name"]
• Reasoning block: [data-testid="reasoning"]
• Confirmation alert: [data-testid="confirmation"]
• Agent card: [data-testid="agent"]
• Task card: [data-testid="task"]
• Conversation area: [data-testid="conversation"]

Asserting a specific tool was invoked:

// Find a tool card that contains a specific tool name
const toolCard = page.locator('[data-testid="tool-invocation"]').filter({
  has: page.locator('[data-testid="tool-name"]', { hasText: /toolname/i }),
})
await expect(toolCard.first()).toBeVisible({ timeout: 30_000 })

Asserting a tool was NOT invoked:

await page.waitForTimeout(5_000)
await expect(
  page.locator('[data-testid="tool-invocation"] [data-testid="tool-name"]').filter({ hasText: /toolname/i })
).toHaveCount(0)

Auto-approving permission dialogs (for tests that trigger tool calls): LLM tool calls may require user approval which blocks the test. Use autoApprove to auto-click "Allow" in the background:

import { autoApprove } from './helpers'

const approver = autoApprove(page)
await sendMessage(page, 'prompt that triggers tool calls')
await waitForResponse(page)
// ... assertions ...
approver.abort()

Step 5: Report

After writing the file, tell the user:

1. The file path created
2. How to run it: pnpm test:e2e -- --grep "test describe name" or pnpm test:e2e e2e/filename.spec.ts
3. Any assumptions you made about selectors that might need adjustment

Rules

• Always inspect the page first via Chrome DevTools MCP before writing selectors. Never guess.
• If a page/dialog you need to see is not currently visible, navigate to it via clicks, inspect, then go back.
• Use generous timeouts for AI responses (30s) since they depend on external services.
• For assertions about absence (something should NOT exist), add a page.waitForTimeout(5_000) first to ensure the response is complete.
• Do NOT modify any existing source code. Only create/edit files in e2e/.
• Keep tests independent — each test should set up its own state.
• Use import('@playwright/test').Page for type annotations in helper functions to avoid import issues.