Selector Strategy and Fallback Generation Prompt Template

This prompt is designed for SDETs and automation engineers who need to generate resilient, maintainable element locators for UI test automation. It produces a prioritized selector chain with fallback logic, staleness handling, and framework-specific guidance. The core job-to-be-done is translating a UI element description, a snippet of DOM, or a component specification into a production-grade locator strategy that survives DOM refactors and reduces flaky test failures caused by brittle selectors.

Use this prompt when you have a clear target element, know which UI framework (React, Angular, Vue, etc.) and test framework (Playwright, Selenium, Cypress) you are targeting, and can provide either a DOM snippet, a component name, or a visual description of the element. The prompt assumes you are generating a locator strategy, not an entire test script. It is most effective when integrated into a test authoring workflow where the generated selector chain is reviewed by a human before being committed to a page object or test file. Do not use this prompt for generating entire test scripts, for accessibility audits, or for performance profiling of selector execution. It is also not suitable when you have no DOM context at all and are guessing at selectors from a screenshot alone.

Before using this prompt, gather the DOM snippet or component specification, identify the test framework and UI framework in use, and define your uniqueness and resilience requirements. After receiving the output, validate the generated selectors against a live DOM or a snapshot test to confirm uniqueness and stability. Avoid treating the output as a final artifact without review—selector strategies should be tested against real DOM states, including loading, error, and empty states, to ensure the fallback chain behaves as expected under all conditions.

This template instructs the model to produce a production-grade selector strategy for a given UI element. It forces the model to think in layers—prioritizing stable, test-specific attributes over brittle structural locators—and to provide explicit fallback logic and staleness handling. Copy the block below, replace the square-bracket placeholders with your specific context, and run it against a capable model.

markdownCopy
You are a senior SDET designing a resilient element locator strategy for a [FRAMEWORK, e.g., Playwright, Selenium, Cypress] test suite. Your goal is to produce a prioritized, maintainable selector chain that survives DOM changes and handles dynamic rendering.

**Context:**
- Application Under Test: [APPLICATION_NAME]
- UI Component/Page: [PAGE_OR_COMPONENT_DESCRIPTION]
- Element to Locate: [ELEMENT_DESCRIPTION, e.g., 'the Submit button inside the registration form']
- Current Fragile Selector (if any): [EXISTING_SELECTOR]
- Framework Version: [VERSION]

**Instructions:**
1.  **Analyze the Element:** Based on the description, propose a prioritized list of at least three selector strategies. The order must be from most to least resilient.
2.  **Prioritization Rules:**
    - **Tier 1 (Highest Priority):** `data-testid`, `data-cy`, `data-test`, or other dedicated test attributes.
    - **Tier 2:** Accessible locators like `role`, `aria-label`, `getByText`, `getByLabel`.
    - **Tier 3:** Semantic CSS selectors based on stable, unique IDs or classes that are not dynamically generated.
    - **Tier 4 (Lowest Priority):** Structural locators like complex CSS or XPath. If you must use XPath, prefer `contains()` or `text()` over fragile absolute paths.
3.  **Fallback Logic:** For each strategy, write a concise code snippet in [FRAMEWORK] that implements a fallback chain. If Tier 1 fails, it should try Tier 2, and so on. Use explicit, condition-driven waits (e.g., `waitForSelector` with a timeout) instead of `sleep` or fixed delays.
4.  **Staleness Handling:** Describe how the script should handle a `StaleElementReferenceException` or detached DOM node. Include a retry loop that re-queries the DOM using the same fallback chain.
5.  **Anti-Patterns to Avoid:** Explicitly list any framework-specific anti-patterns you are avoiding in your solution (e.g., Playwright's `elementHandle` for long-lived references, Selenium's implicit waits mixed with explicit waits).

**Output Format:**
Return your response as a structured markdown document with the following sections:
- **Selector Strategy Table:** A table with columns for Priority, Strategy Type, Selector Value, and Resilience Rationale.
- **Implementation Script:** A single, runnable [FRAMEWORK] code block containing the fallback chain and staleness retry logic.
- **Staleness Handling Explanation:** A brief paragraph explaining the retry mechanism.
- **Anti-Patterns Avoided:** A bulleted list of the specific anti-patterns you avoided.

After copying the template, the most critical adaptation is the Prioritization Rules. If your application has a mature design system with reliable data-testid attributes, you can instruct the model to strictly prefer them and treat any other selector as a fallback. Conversely, if you lack test attributes, you must guide the model toward accessible locators and stable semantic selectors. The Implementation Script section is designed to be dropped directly into a test file, but you should always review the generated wait strategy to ensure timeouts align with your application's performance profile under CI conditions. For high-risk release pipelines, treat the generated selector chain as a draft and require a peer review step before merging.

The selector strategy prompt is designed to be called programmatically from your test authoring workflow, not as a one-off chat interaction. When an SDET identifies a UI element that needs a resilient locator chain, they should invoke this prompt with the element's HTML context, the application framework in use, and any existing brittle selectors that have failed. The prompt returns a prioritized selector array that your harness can validate before committing to the test repository. This is a generation-time prompt, not a runtime prompt—it runs during test development, not during test execution. The output feeds directly into your Page Object Model or test script as the canonical locator strategy for that element.

Integration pattern: Build a thin CLI tool or IDE extension that accepts an HTML snippet and framework identifier, calls the LLM with this prompt template, and writes the validated output into a locator registry file. The harness must enforce three validation gates before accepting the generated selectors: (1) Uniqueness check—run the proposed selectors against a static DOM snapshot or live page to confirm exactly one element matches; if multiple elements match, reject and request refinement. (2) Framework anti-pattern scan—reject selectors that use framework-generated dynamic attributes (e.g., Angular's _ngcontent-*, React's data-reactid, or auto-generated CSS module hashes) unless explicitly allowed by a [FRAMEWORK_ALLOW_LIST] parameter. (3) Fallback ordering verification—confirm that the chain progresses from most-stable to least-stable selectors (data-testid → aria → text → CSS → XPath) and that each fallback is independently resolvable. Log every generation attempt with the input context, generated selectors, validation results, and the SDET who approved the final output for auditability.

Retry and escalation logic: If validation fails, the harness should automatically retry with enriched context—append the specific validation failure message to the prompt's [CONTEXT] field and re-invoke. Limit automatic retries to two attempts. If both fail, surface the element to a human SDET with the failed attempts, the DOM context, and a pre-filled ticket suggesting manual selector authoring. For high-risk application surfaces (payment flows, authentication, data deletion), require explicit human approval in the harness UI before the generated selectors can be merged, regardless of validation pass status. Model choice: Use a model with strong HTML and CSS parsing capabilities; avoid models that hallucinate DOM structures. What to avoid: Do not use this prompt at test runtime to recover from stale element exceptions—that path leads to unpredictable selector regeneration mid-execution and makes test results non-deterministic. Instead, use the prompt during development to build resilient locators upfront, and handle runtime staleness with explicit wait strategies and periodic locator health checks in CI.