Page Object Model Generation Prompt for Test Cases

This prompt is designed for SDETs and automation engineers who need to scaffold maintainable Page Object Model (POM) classes from UI descriptions, wireframes, or existing procedural test scripts. Use it when you have a defined page or component with known interactions and want to produce a POM class with encapsulated selectors, action methods, and assertion helpers before writing automation code. The ideal input is a structured description of the page's purpose, key elements (with their semantic meaning, not just raw selectors), and the primary user workflows that traverse this page. This prompt is most effective early in the automation development cycle, acting as a design tool that enforces consistency and reduces the accumulation of brittle, copy-pasted locators across a test suite.

The prompt assumes you can describe the page structure, key elements, and user workflows in natural language. It is not a replacement for framework-specific runtime behavior tuning, nor does it handle dynamic element resolution strategies that require live DOM inspection. Do not use this prompt to generate code for a page you haven't designed or explored; the output quality is directly proportional to the clarity of your input description. For example, a good input specifies 'a login form with a username text field, a password field with a show/hide toggle, a 'Sign In' button, and a 'Forgot Password' link,' rather than just 'a login page.' The prompt will then generate a class with methods like login(username, password), togglePasswordVisibility(), and clickForgotPassword(), each encapsulating its own selectors. The generated code should be treated as a first draft that requires human review for selector strategy, framework-specific conventions, and cross-page coupling risks before being committed to a repository.

After generating the POM scaffold, your next step is to review the output against your team's specific coding standards and the real, rendered DOM. Pay close attention to the 'Review Criteria' section of the output, which flags potential issues like methods that assume a single responsibility but have side effects, or selectors that are overly generic. Avoid using the generated class directly in a critical path without first validating its selectors against your actual application under test and integrating it with a concrete test to ensure the action methods and assertion helpers behave as expected in a live browser context.

This prompt template is designed for SDETs and automation engineers who need to scaffold maintainable Page Object Model (POM) classes. It takes a description of a UI component, page, or an existing brittle test script and produces a well-structured class with encapsulated selectors, action methods, and assertion helpers. The goal is to enforce separation of concerns, making tests more readable and less fragile by abstracting the UI's implementation details away from the test logic.

markdownCopy
You are a senior SDET specializing in test automation architecture and the Page Object Model pattern. Your task is to generate a Page Object class based on the provided context.

**INPUT CONTEXT:**
[UI_DESCRIPTION_OR_EXISTING_SCRIPT]

**TARGET LANGUAGE & FRAMEWORK:** [LANGUAGE_AND_FRAMEWORK, e.g., TypeScript with Playwright, Java with Selenium]

**OUTPUT SCHEMA:**
Generate a single, well-commented class that adheres to these rules:
1.  **Encapsulated Selectors:** All element locators must be defined as private properties at the top of the class. Use a prioritized strategy: `data-testid` first, then accessible roles/labels, and finally stable CSS selectors. Do not use XPath unless absolutely necessary.
2.  **Action Methods:** Public methods should represent high-level user actions (e.g., `login()`, `searchForProduct()`, `addItemToCart()`). Each method must return either `void` or a new Page Object representing the navigated-to page.
3.  **Assertion Helpers:** Include public methods that return boolean promises or perform explicit assertions for common state checks (e.g., `isErrorMessageVisible()`, `getCartItemCount()`). These methods should not contain test logic.
4.  **Explicit Waits:** Do not use `sleep()` or fixed delays. Use framework-native explicit wait strategies (e.g., Playwright's `waitForSelector`, Selenium's `WebDriverWait`) before any element interaction.
5.  **Constructor:** The constructor should accept the test runner's page or driver instance and assert that a unique element on the page is visible to confirm navigation was successful.

**CONSTRAINTS:**
- Do not generate the test case itself, only the Page Object.
- Keep methods focused on a single responsibility.
- If the input describes a multi-step workflow, model each distinct page or state as a separate class suggestion in a comment.
- Provide a brief comment at the top of the class explaining its responsibility boundary.

To adapt this template, replace the [UI_DESCRIPTION_OR_EXISTING_SCRIPT] placeholder with a detailed description of the UI component, a screenshot's text description, or the raw code of a script you want to refactor. The [LANGUAGE_AND_FRAMEWORK] placeholder should be a precise string like TypeScript with Playwright or Python with Selenium. After generating the POM, you should immediately review it for cross-page coupling risks and ensure the selectors are resilient to minor UI changes. The next step is to integrate this class into a test harness and validate it against a real environment.

The Page Object Model generation prompt is not a one-shot code generator you trust blindly. It is a scaffolding engine that produces a first draft of a POM class. The implementation harness around this prompt must enforce validation, human review, and integration checks before the generated code reaches a shared test repository. Treat the output as a structured suggestion, not a deployable artifact. The harness should capture the input context (UI description, existing test script, or component source), the raw model response, and any post-processing steps so that every generated POM is traceable to its origin.

Wire the prompt into a pipeline that performs at minimum three stages: schema validation, selector sanity checks, and responsibility boundary review. Schema validation should confirm the output parses as valid code in the target language (TypeScript, Python, Java) and contains the required structural elements: a class declaration, a constructor with locator initialization, at least one action method, and at least one assertion helper. Selector sanity checks should flag selectors that rely on unstable attributes like auto-generated CSS classes, absolute XPath indices, or text content that changes with localization. Responsibility boundary review is a manual or LLM-as-judge step that checks whether the generated POM mixes page concerns (navigation, multi-page workflows) that belong in a separate page object or test layer. Each stage should produce a pass/fail signal and a structured reason so the pipeline can decide whether to retry, flag for human review, or reject the output.

For model choice, prefer a model with strong code generation capabilities and structured output support. If your provider supports it, request the output in a typed JSON schema that maps to the POM structure rather than relying on freeform code blocks. This reduces parsing fragility. Set a low temperature (0.0–0.2) to minimize creative variation in selector strategies and method signatures. Implement a retry budget of two attempts: if the first output fails schema validation, feed the validation errors back into a retry prompt that includes the original input plus the specific failure reasons. If the second attempt also fails, escalate to a human reviewer with the input, both outputs, and the validation report. Log every generation attempt with the input hash, model version, output, validation results, and reviewer decision. This audit trail is essential when a generated POM later causes a flaky test and the team needs to trace its origin.

Do not allow generated POMs to be committed directly to the test repository without human approval. The harness should open a pull request or create a review task that includes the generated code, the selector chain with fallback rationale, and a diff against any existing page object for the same page. Reviewers should verify that action methods encapsulate wait strategies internally, that assertion helpers return boolean or assertion results rather than performing side effects, and that the POM does not import test-runner-specific assertions directly. After approval, run the generated POM through a smoke test that instantiates the class against a live or mocked page and calls each action method once. A POM that cannot survive a basic instantiation-and-call smoke test should not enter the repository, regardless of how clean the code looks.