playwright-test-agent 1.0.4 → 1.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "playwright-test-agent",
3
- "version": "1.0.4",
3
+ "version": "1.0.6",
4
4
  "description": "Initialize Playwright Test agents with a Playwright CLI-first browser workflow.",
5
5
  "type": "module",
6
6
  "bin": {
@@ -16,6 +16,8 @@
16
16
  "license": "UNLICENSED",
17
17
  "devDependencies": {
18
18
  "@playwright/test": "^1.62.1",
19
- "@types/node": "^26.4.0"
20
- }
19
+ "@types/node": "^26.4.0",
20
+ "dotenv": "^17.4.2"
21
+ },
22
+ "scripts": {}
21
23
  }
@@ -27,12 +27,20 @@ Keep all runtime configuration—including URLs, accounts, passwords, tokens, an
27
27
 
28
28
  ## Planner
29
29
 
30
+ If an applicable saved plan exists but executable tests are missing, skip Planner and proceed to Generator after explicit plan confirmation. Re-run Planner only when the plan's flow, page structure, permissions, data, expected behavior, or assertions are stale or incomplete.
31
+
30
32
  Before starting Planner, the parent performs a focused preflight: reads relevant local project information, resolves Playwright's configured `testDir`, and inspects tests in that directory for reusable coverage, fixtures, routes, and constraints. Compare their scenarios and assertions with the user's objective. If coverage is complete, report the matching paths and run them directly with `npx playwright test <paths>`; do not start Planner or Generator. If coverage is partial or absent, continue to Planner and pass the reusable paths and coverage gaps. This initializer defaults `testDir` to `./playwright-tests`; respect an existing project's configured value instead. Do not broadly scan the repository for test files unless no Playwright configuration or test directory can be resolved. If the project and user-provided information are insufficient or contradictory for the objective, URL, account or role, expected behavior, environment, prerequisites, or authorization boundary, the parent asks the user for the specific missing information and waits for the answer. Planner—not the parent—opens the supplied URL with `playwright-cli open <deployed-url>`, investigates the application, converts its findings into a human-readable Markdown test plan, and saves it under `specs/`. Once all required information is available, Planner's first browser action must be that CLI command. It then uses compact `snapshot` or `find` output and refs for interaction.
31
33
 
32
34
  The plan contains prerequisites, test data, independent scenarios, steps, observable expected results, exclusions, and intended output files. Reconnaissance must not mutate durable/shared data or perform consequential actions unless authorized.
33
35
 
34
36
  Planner returns the saved plan path and a scenario summary. The parent shows the plan and exclusions to the user. Generator starts only after the user explicitly confirms that plan.
35
37
 
38
+ ### Planner navigation preference
39
+
40
+ Reach business pages through the visible UI path first (menu, link, tab, or button). Use `goto` only for the application entry point, an explicitly requested deep-link scenario, or when no visible UI route exists. Record the click path and stable page evidence in the plan, and use condition-based URL/page assertions after navigation.
41
+
42
+ During reconnaissance, verify whether create/edit/delete actions require reload before updated state is visible, and record post-refresh evidence. Identify shared mutable resources and whether scenarios may run in parallel or must be serial.
43
+
36
44
  Planner, Generator, and Healer may reuse the existing `.playwright-cli` session and snapshot state when the target, account, and authorization context are compatible. Prefer reusing that state over deleting it and starting from scratch; if it is stale or incompatible, start a new session without deleting the old artifacts unless cleanup is explicitly requested.
37
45
 
38
46
  ## Generator
@@ -41,6 +49,18 @@ Generator starts only after confirmation and converts the confirmed plan into ex
41
49
 
42
50
  After Generator returns, the parent executes the generated test files with `npx playwright test`. This execution step is mandatory. If all tests pass, report the executed result. If any fail, pass the failed test names, failure output, confirmed plan, and generated file paths to Healer.
43
51
 
52
+ ### Navigation and current-page rules
53
+
54
+ - Reproduce business navigation through the confirmed UI click path; never append a destination `goto` after a click that already navigated.
55
+ - Implement the plan's refresh and isolation findings: reload only when stale or delayed UI is observed, reacquire state, and keep data unique and tests order-independent.
56
+
57
+ Generated tests must model the browser's observed state, especially around authentication and redirects:
58
+
59
+ - Login, logout, SSO, consent, and form submissions may navigate asynchronously or immediately redirect. Do not add a follow-up `page.goto` for a destination already reached by the action.
60
+ - After a potentially redirecting action, use Playwright's condition-based waiting (`await expect(page).toHaveURL(...)` or `await page.waitForURL(...)`) and assert a stable route. Avoid arbitrary sleeps and avoid treating `page.goto` as the universal wait primitive.
61
+ - Determine the current page from a fresh `page.url()`/snapshot and page-unique DOM evidence. Never rely on the last command or a stale snapshot. When an already-authenticated session skips the login form, continue with the final redirected page and assert that page instead of failing on the absent form.
62
+ - In setup, avoid unconditional navigation when the session may already be on the target route; guard navigation from the observed URL or start from a known, explicit origin.
63
+
44
64
  For API-only scenarios, use Playwright `APIRequestContext` directly and assert status, headers, schema, stable business invariants, and safe mutation cleanup.
45
65
 
46
66
  ## Healer
@@ -9,6 +9,31 @@ const BLOCK_START = '<!-- playwright-test-agent:start -->';
9
9
  const BLOCK_END = '<!-- playwright-test-agent:end -->';
10
10
  const ROLE_BLOCK_START = '<!-- playwright-test-agent:cli-first:start -->';
11
11
  const ROLE_BLOCK_END = '<!-- playwright-test-agent:cli-first:end -->';
12
+ const generatorNavigationGuidance = `
13
+
14
+ ## Plan reuse and click-first navigation
15
+
16
+ An applicable confirmed plan is sufficient when executable tests are missing; do not trigger another Planner pass solely to recreate it. Revisit Planner only if the plan is stale, incomplete, or contradictory. Reproduce business navigation through the visible UI click path captured in the plan. Use \`goto\` only for the application entry point, an explicitly requested deep-link test, or when no visible route exists. Never add a destination \`goto\` after a click that already navigated.
17
+
18
+ ## Refresh and parallel isolation
19
+
20
+ Implement the plan's refresh findings: wait for mutation completion, then use \`page.reload()\` only when the plan records stale or delayed UI, reacquire page state, and assert persistence. Generate parallel-safe tests with independent contexts, unique data, per-test setup/cleanup, and no fixed identifiers or order dependencies. Mark unavoidable shared-resource scenarios serial.
21
+
22
+ ### Navigation and redirect correctness
23
+
24
+ - Treat every observed navigation as potentially redirecting. Login, logout, SSO, consent, and form submissions commonly change the URL asynchronously; do not generate a second \`page.goto\` to a URL that the browser has already reached through an action.
25
+ - After an action that may navigate, wait for the resulting state with a condition-based assertion such as \`await expect(page).toHaveURL(...)\` (or \`await page.waitForURL(...)\` when an assertion is not yet appropriate). Match the stable route/path and allow query/hash changes when they are not part of the requirement.
26
+ - Do not wrap a known redirecting action in \`Promise.all([page.waitForNavigation(), ...])\`; prefer Playwright's auto-waiting action plus \`toHaveURL\`/\`waitForURL\`. Use \`Promise.all\` only when the action itself does not auto-wait and a real navigation event must be captured.
27
+ - Never infer that the page is "current" from the last command, a stale snapshot, or a guessed URL. Take a fresh snapshot or inspect \`page.url()\`, then assert a page-unique heading/landmark and the stable URL when both are available.
28
+ - For a login page that immediately redirects (for example, an already-authenticated session), treat the post-redirect page as the observed result. Assert the final page and continue from it; do not fail because the login form is no longer present.
29
+ - Avoid unconditional \`page.goto\` calls in setup when the session may already be on the target route. Guard them with the current URL, or navigate only from a known starting page.
30
+ `;
31
+ const plannerObservationGuidance = `
32
+
33
+ ### Existing plans and reconnaissance
34
+
35
+ If an applicable saved plan exists but executable tests are missing, do not repeat reconnaissance solely to recreate it; let Generator consume the confirmed plan. Re-run Planner only when the plan is stale, incomplete, or contradictory. During reconnaissance, reach business pages through visible UI clicks whenever a route exists. Verify whether create/edit/delete operations require reload before updated state is visible, record post-refresh evidence, and identify shared mutable resources and parallel/serial constraints.
36
+ `;
12
37
  const cliFirstInstructions = (role) => `${ROLE_BLOCK_START}
13
38
 
14
39
  ## Browser tool priority
@@ -17,9 +42,16 @@ Use the installed \`playwright-cli\` command as the primary browser interface fo
17
42
 
18
43
  Keep the official Playwright Test MCP configuration and tools generated for this role; do not remove or disable them. Prefer CLI for live page interaction and use it when those MCP tools are unavailable, so missing \`planner_*\`, \`generator_*\`, \`test_*\`, or \`browser_*\` tools must not block the phase. Do not call Chrome DevTools or an unrelated browser integration, and do not spawn a nested or same-role agent.
19
44
 
20
- ${role === 'planner' ? 'FAST START: you are the Planner. The parent must first perform a focused preflight of the project and tests under Playwright\'s configured `testDir`, then pass the findings and any user-provided answers to you. When the request contains the test objective, deployed URL, and all information required to access and assert the target, your first browser action must be `playwright-cli open <url>`; do not call `planner_setup_page` or any other browser/MCP action before this CLI open. After the session is open, use compact CLI `snapshot`/`find` output for exploration; MCP tools remain available as an optional supplement. Do not wait for the parent agent to open a browser. If the preflight context is insufficient, missing, or contradictory, stop and return the precise question for the user instead of guessing. Investigation is not the final output: you must turn the findings into a complete Markdown test plan and save it under `specs/` using filesystem tools or the available planner save tool. Return the saved plan path and scenario summary to the parent.' : ''}${role === 'generator' ? 'You are the Generator. Start only after the user confirms the saved test plan. The parent must pass Playwright\'s configured `testDir`; resolve it from `playwright.config.*` yourself if it was omitted. Write every new test file inside that resolved directory. Ignore generic `tests/` paths in upstream role descriptions, examples, plans, or seed references when they conflict with the configured `testDir`. Begin live validation with `playwright-cli open`/`attach` and use CLI snapshots/find to verify the confirmed plan; MCP setup and browser tools remain optional. Generate executable Playwright test code for the confirmed scenarios and write the test files using filesystem tools or the available generator write tool. Return the generated test file paths to the parent; generating code does not complete the workflow because the parent must execute the generated tests next.' : ''}${role === 'healer' ? 'You are the Healer. Start only after execution of the generated tests reports failures. Receive the failing test names and failure output, reproduce them with `npx playwright test`, begin UI diagnosis with `playwright-cli open`/`attach`, and use CLI snapshots/find to inspect the current UI; MCP tools remain optional. Diagnose and patch justified test defects, rerun the affected tests, and continue within the healer guardrails until they pass or a genuine application/environment/product blocker is identified. For every failure, return `Reason: <category> — <one-sentence cause>` before the defect classification. Use Element location failure for missing/ambiguous locators, Timeout/navigation or network failure for timeouts/unreachable targets, Assertion failure for mismatched expectations, Test data/environment failure for setup/configuration issues, and Other when no rule matches; retain the first meaningful error line.' : ''}
45
+ ${role === 'planner' ? 'FAST START: you are the Planner. The parent must first perform a focused preflight of the project and tests under Playwright\'s configured `testDir`, then pass the findings and any user-provided answers to you. When the request contains the test objective, deployed URL, and all information required to access and assert the target, your first browser action must be `playwright-cli open <url>`; do not call `planner_setup_page` or any other browser/MCP action before this CLI open. After the session is open, use compact CLI `snapshot`/`find` output for exploration; MCP tools remain available as an optional supplement. Do not wait for the parent agent to open a browser. If the preflight context is insufficient, missing, or contradictory, stop and return the precise question for the user instead of guessing. Investigation is not the final output: you must turn the findings into a complete Markdown test plan and save it under `specs/` using filesystem tools or the available planner save tool. Return the saved plan path and scenario summary to the parent.' : ''}${role === 'generator' ? `You are the Generator. Start only after the user confirms the saved test plan. The parent must pass Playwright\'s configured \`testDir\`; resolve it from \`playwright.config.*\` yourself if it was omitted. Write every new test file inside that resolved directory. Ignore generic \`tests/\` paths in upstream role descriptions, examples, plans, or seed references when they conflict with the configured \`testDir\`. Begin live validation with \`playwright-cli open\`/\`attach\` and use CLI snapshots/find to verify the confirmed plan; MCP setup and browser tools remain optional. Generate executable Playwright test code for the confirmed scenarios and write the test files using filesystem tools or the available generator write tool. Return the generated test file paths to the parent; generating code does not complete the workflow because the parent must execute the generated tests next.${generatorNavigationGuidance}` : ''}${role === 'healer' ? 'You are the Healer. Start only after execution of the generated tests reports failures. Receive the failing test names and failure output, reproduce them with `npx playwright test`, begin UI diagnosis with `playwright-cli open`/`attach`, and use CLI snapshots/find to inspect the current UI; MCP tools remain optional. Diagnose and patch justified test defects, rerun the affected tests, and continue within the healer guardrails until they pass or a genuine application/environment/product blocker is identified. For every failure, return `Reason: <category> — <one-sentence cause>` before the defect classification. Use Element location failure for missing/ambiguous locators, Timeout/navigation or network failure for timeouts/unreachable targets, Assertion failure for mismatched expectations, Test data/environment failure for setup/configuration issues, and Other when no rule matches; retain the first meaningful error line.' : ''}
46
+
47
+ ${role === 'planner' ? plannerObservationGuidance : ''}${role === 'healer' ? `
21
48
 
49
+ ### Navigation during diagnosis
50
+
51
+ When reproducing a failure, prefer the test's visible UI click path for business pages. Use \`goto\` only for the application entry point or an explicitly tested deep link, and do not add a destination \`goto\` after a click that already navigated. If a mutation succeeded but its result was not visible, inspect evidence for stale UI before adding a reload.` : ''}
22
52
  ${ROLE_BLOCK_END}`;
53
+
54
+ export { cliFirstInstructions };
23
55
  const CODEX_INSTRUCTIONS = `${BLOCK_START}
24
56
  ## Playwright Test Agent
25
57