Engineering

Selenium Test Prompt

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

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.

Workflow

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

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

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.

Related Resources

Explore more resources that work well with this one.