File size: 4,042 Bytes
7149fa6 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 |
## Prompt 1 – Accessibility Enhancement for Test Resilience
**Objective:**
Prepare React components by improving accessibility.
---
Analyze the following React component and enhance it to maximize accessibility and E2E test robustness.
Focus on the following:
1. **Add appropriate ARIA attributes** to identify the roles, states, and properties of UI elements.
2. **Ensure full keyboard navigation support**, including tab order and focus visibility.
3. **Use semantic HTML elements** instead of generic containers (`<div`, `<span`) where appropriate.
4. **Assign descriptive `aria-label` or `aria-labelledby` attributes** to elements lacking textual content.
5. **Integrate `data-testid` or `data-qa` attributes** as a fallback for selectors when ARIA or semantics are insufficient.
6. **Provide improved JSX output**, with:
- Inline comments explaining each accessibility change
- Justification for replacing or modifying tags and attributes
The final version should be:
- Fully accessible
- Ready for stable E2E testing
- Maintainable and understandable by frontend developers
---
## Prompt 2 – Page Object Model Generation for E2E Testing
**Objective:**
Generate Playwright Page Object Models (POM) that enable robust and maintainable E2E test automation by encapsulating UI interactions.
---
Based on the following application page HTML structure, generate a comprehensive Playwright Page Object Model using TypeScript.
Follow these best practices:
1. **Use multiple selector strategies**:
- Prioritize `aria-*` attributes for accessibility-aware selectors
- Use meaningful `text` content where applicable
- Fallback on `data-testid` or `data-qa` attributes
- Avoid brittle selectors like raw CSS class names or nth-child unless necessary
2. **Implement self-healing patterns**, such as:
- Fallback selectors for dynamic content
- Try-catch wrappers or optional waits for conditionally rendered elements
3. **Create methods that reflect user behavior**, such as:
- `fillForm(data)`
- `submitLogin()`
- `navigateToSection(sectionName)`
- `assertErrorMessage(message)`
4. **Ensure type safety with TypeScript**:
- Define proper return types and argument interfaces
- Avoid usage of `any`
5. **Encapsulate logic to reduce test duplication**:
- PageObject should expose business-level actions, not implementation details
Structure the code as:
- A class per page/component
- Constructor receiving the Playwright `Page` instance
- Public methods for reusable user interactions
- Private helpers where necessary
---
## Prompt 3 – Gherkin to Playwright E2E Test Generation
**Objective:**
Transform business-readable scenarios (in Gherkin format) into executable Playwright E2E tests using TypeScript and the Page Object Model pattern.
Convert the following Gherkin test scenarios into fully functional Playwright tests using TypeScript.
Guidelines:
1. **Use the previously generated Page Object Models** to drive interactions. Avoid direct DOM calls in the test files.
2. **Implement each step from the Gherkin scenario**:
- Use `beforeEach`/`afterEach` for setup and cleanup
- Structure tests using `test.describe`, `test.beforeEach`, `test`, and assertions
3. **Follow the Arrange–Act–Assert (AAA) pattern**:
- Arrange: set up environment, mocks, or seed data
- Act: execute user interactions
- Assert: validate outcomes (UI feedback, navigation, etc.)
4. **Handle authentication or navigation as reusable helpers** (e.g., login as user, navigate to dashboard)
5. **Write meaningful assertions**:
- Expect visibility, text content, form validity
- Assert navigation URLs or component presence
6. **Incorporate error handling and traceability**:
- Use `try/catch` when simulating edge/error cases
- Add `test.info().attach()` or screenshots if supported
The generated test should be:
- Readable and maintainable
- Robust against UI changes
- Closely aligned with user stories and business logic
|