ui-test-selenium

Selenium 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 Selenium UI automation testing workflow.
When the project already uses relevant tools, or you want a tool-specific solution that can be directly implemented.

Use Markdown by default. Do not extend the output format unless the request explicitly requires another format.

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

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis in references/domain-decision-example.md .
prompts/ui-test-selenium.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.

Pin the project's Selenium/binding/browser/driver/Grid versions, capabilities, and runner, and generate compatible configuration and POM; do not build a topology on your own if no Grid is provided, and diagnose version conflicts first.
Explicitly wait for observable conditions (element interactable, business state/window/URL achieved), and distinguish presence/visibility/business ready; do not mix implicit/explicit waits or use fixed sleep to fix all timing issues.
When stale occurs due to rerender, re-locate using a stable locator and wait for the new state, with limited retries according to the project strategy; do not blindly replay payment actions and introduce duplicate effects.
Each parallel session has independent accounts/business keys; try/finally driver.quit, and on failure retain screenshots/logs/Grid session and the original error; rerendering, business failures, and abnormal exits all require checking resource handling and failure propagation.

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

Start from the prompt file and only supplement context that truly affects the result.
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 business assertions, failure propagation, or isolation of generated assets, read evals/fixtures/checkout-app/README.md, and use local good/bug/timeout comparisons; execute at runtime only when explicitly specified.