Engineering

Selenium Test Prompt

Explicit waits, stale-element handling, drivers that actually quit — Selenium regression tests that hold the legacy fort.

Open in Test Case Prompt Generator

Overview

Selenium suites rot predictably: Thread.sleep calls accumulate, stale element exceptions get try-catched into silence, and leaked driver sessions poison CI. This setup generates a Selenium regression contract for legacy-critical paths with the discipline that keeps WebDriver suites alive: explicit waits with expected conditions (never sleep), re-locating elements after DOM changes instead of caching them, locators that survive DOM churn, and teardown that always quits the driver. Regression strategy pins today's behavior — the job legacy suites exist to do.

How to use this resource

Pin the critical paths first

Regression strategy: the suite documents what works today, before anything changes.
Enforce the wait discipline

WebDriverWait + expected conditions everywhere — the contract treats sleep as a defect.
Check the teardown

Driver.quit in teardown, always — leaked sessions are the silent CI killer.

Why This Works

Explicit-wait discipline addresses Selenium's defining flake source at the source
Stale-element rules encode the WebDriver lesson every team learns the hard way
Regression strategy matches what Selenium suites are actually for in 2026: holding the fort

Best for

Established Selenium estates that aren't migrating this quarter
Legacy UIs where Playwright adoption isn't on the table yet
Regression suites guarding paths nobody dares touch

Not for

New projects — Playwright mode generates the same journey with less flake surface
Deciding whether to migrate frameworks — that's a team decision, not a prompt

Use cases

Protecting legacy admin panels with regression coverage
Replacing Thread.sleep with explicit waits at generation time
Pinning critical paths before a framework migration

FAQ

Should I generate Selenium tests for a brand-new project with this?

Not the intended use — it targets established Selenium estates guarding legacy critical paths. For new projects the resource points to Playwright mode, which generates the same journey "with less flake surface." This setup is for regression coverage on paths nobody dares touch, where a framework migration isn't on the table this quarter.

How does the generated test avoid the flaky waits Selenium is known for?

The FRAMEWORK GUIDANCE treats sleep as a defect: it mandates explicit waits via WebDriverWait plus expected conditions and forbids Thread.sleep, re-locates elements after DOM changes instead of caching WebElements, and prefers IDs and data attributes over brittle XPath positions. The generated file runs in your own environment, so you still execute and confirm the suite is green.

Why does the prompt keep tests for legacy behavior that looks wrong?

Regression strategy pins today's behavior. For untested legacy code the TEST STRATEGY writes characterization tests that "assert actual current output, even where it looks wrong, and flag the suspicious cases," because the suite's job is documenting what the system does now before anything changes — not correcting it. It also forbids weakening assertions to make tests pass.

Customize This Resource

Opens this setup in Test Case Prompt Generator. Generate to get the full test contract — then adjust the strategy, framework, coverage, and depth.

Open in Test Case Prompt Generator

Prompt Template

Copy it as-is, or use Open in Test Case Prompt Generator to load it pre-filled and customize it with your own context.

TESTING OBJECTIVE
Protect the legacy admin panel's critical paths with Selenium regression tests.
Strategy: regression tests — pin the current behavior so future changes cannot silently alter it.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the behavior under protection here]

TEST STRATEGY
- Protect existing behavior: the tests document what the system does TODAY, before anything changes.
- Cover previously-fixed bugs by name — each known failure gets a test that would catch its return.
- For untested legacy code, write characterization tests: assert actual current output, even where it looks wrong, and flag the suspicious cases.
- Pin output formats exactly where downstream consumers parse them.

COVERAGE AREAS
Happy Path:
- The primary success path with realistic, typical inputs
- The most common variations users actually exercise
- Expected outputs asserted precisely — values and shape, not just "no exception"
Regression:
- Current behavior pinned before any change lands
- Previously-fixed bugs covered by name, one test each
- Output formats asserted exactly where consumers parse them

FAILURE SCENARIOS
Each of these gets at least one test:
- A previously-fixed bug reappears after a refactor
- Behavior drifts in code paths the change was not supposed to touch
- An output format changes shape and breaks its consumers
- An edge case that worked before stops working

TEST DATA GUIDANCE
- Use realistic, production-shaped data — names, amounts, and dates that could exist.
- Build complex objects with builders or factories, not hand-assembled literals repeated per test.
- Name boundary data for its intent (maxLengthName, expiredToken), not its value.
- Never share mutable fixtures between tests.

FRAMEWORK GUIDANCE
Framework: Selenium.
- Use explicit waits (WebDriverWait + expected conditions) — never Thread.sleep.
- Handle stale elements: re-locate after DOM changes instead of caching WebElements across actions.
- Choose locators that survive DOM churn: IDs and data attributes over brittle XPath positions.
- Always quit the driver in teardown — leaked browser sessions poison CI.

OUTPUT FORMAT
- Return one complete, runnable test file in Selenium.
- Group tests by coverage area, with a comment header per group.
- Each test: arrange-act-assert structure, one behavior per test.
- Cover every selected coverage area systematically — each coverage item above gets at least one test.
- Parametrize repetitive cases instead of copy-pasting tests.
- Name tests so a failure message alone identifies the broken behavior.

ASSUMPTIONS
- After the tests, list every assumption you made about unspecified behavior under an ASSUMPTIONS heading.
- Where the code's intent is ambiguous, test the most likely intent and flag the ambiguity.
- List GAPS: behaviors you could not test with the information given.

NON-GOALS
- Do not rewrite or "improve" the implementation code — test it as it is.
- Do not refactor the architecture to make it more testable; flag testability problems instead.
- Do not invent requirements — test only specified or clearly implied behavior.
- Do not weaken assertions to make tests pass.

More resources from Test Case Prompt Generator

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Unit Test Prompt — Isolation Done Right

Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.

Engineering

Resource

Agent Safety & Refusal Evaluation Prompt

Test the two failure directions — does the agent refuse what it must, and does it stay helpful on the benign requests it shouldn't over-refuse?

AI Agents

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Test Case Prompt Generator

Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.