ui-test-puppeteer

Puppeteer UI Automation Testing

English version: see the matching English skill.

When to Use

When you need to produce a test plan or automation design for a Puppeteer UI automation testing workflow.
When the project already uses the relevant tools, or you want a tool-specific plan that can be directly put into practice.

Markdown is used by default. Unless the request explicitly requires another format, do not expand the output format further.

Open prompts/ui-test-puppeteer.mdand use it as the main prompt.
Provide the real project context: scope, environment, constraints, risks, dependencies, and expected deliverables.
If the input is incomplete, first return a usable first version and clearly note the missing information and assumptions.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recomputation basis.
prompts/ui-test-puppeteer.md: The main prompt for this skill.
references/framework-spec.md: Tool-specific structure and coverage description.
references/setup-and-ci.md: Installation, execution, and CI instructions.
examples/sample-context.md: Example request context.
scripts/run-tests.sh: Lightweight local execution entry point.

Read the actual Puppeteer/Node/browser and launch configuration/support scope; list version or browser incompatibilities separately as CONFIG_ERROR, and do not treat a successful launch as compatibility for all features.
For a new window, locate it from the target creation event/associated opener and wait for a usable page, then check the target URI and permissions; separate navigation waiting from business readiness, use the page's real state as the oracle, and a fixed sleep has no such evidence.
Use try/finally to close the old and new pages and any self-created browser, preserving the original timeout/load failure exceptions; record the primary error and cleanup errors separately, and do not swallow exceptions and then return success.
The minimal fixture includes normal payment, wrong state, a new window, load failure, and timeout; verify business state/subject as well as screenshots/URL/logs/version, and do not upgrade file generation or successful HTTP loading into a business pass.

Do not directly give a generic plan when the scope is vague and context is lacking.
Do not treat all modules and scenarios as equally important.
Do not skip stating assumptions and missing information.

Start from the prompt file and only add context that truly affects the results.
Keep the output risk-driven and directly usable for execution or review.
When information is incomplete, first provide a usable version, then clearly mark the gaps.
When verifying the business assertions, failure propagation, or isolation of generated assets, read evals/fixtures/checkout-app/README.md, and use the local good/bug/timeout comparisons; execute only when the runtime is explicit.