Given the following DOM structure: [DOM HTML Structure]

Generate Playwright test code in TypeScript to perform [specific action].

Here is the page URL: [URL]

Requirements:

1. IMPORTANT - Use only modern Playwright Locator API:

• Always use page.locator() or the recommended getBy* methods
• For multiple elements, use .all() method instead of deprecated $$ syntax
• Never use deprecated page.$() or page.$$() syntax
• Example for multiple elements:
  • Use: await page.locator('.item').all()
  • Or: await page.getByRole('listitem').all()
  • Don't use: await page.$$('.item')

2. Use only recommended Playwright locators in this priority order:

• Always use the html ids or names as css locators if id and name are present
• Role-based locators (getByRole) ONLY when the element has a unique role in its context
  • Bad: page.getByRole('list') when there are multiple lists
  • Good: page.getByRole('list', { name: 'Todo Items' }) or use a more specific selector
• Label-based locators (getByLabel)
• Text-based locators (getByText)
• Test ID-based locators (getByTestId)
• CSS selectors when you need to be more specific (e.g., '.todo-list' for a specific list)
• Only use other locators if above options are not applicable

3. IMPORTANT - Handling ambiguous elements:

• When dealing with elements that might appear multiple times (like lists, buttons, inputs):
  • Always check if the role/text/label alone is unique enough
  • If not, use more specific selectors or add additional filters:
    • Use name option: page.getByRole('button', { name: 'Submit' })
    • Use exact option: page.getByText('Submit', { exact: true })
    • Use parent containers: page.locator('.todo-section').getByRole('list')
    • Use class/id selectors: page.locator('.todo-list')
  • Avoid ambiguous locators that might match multiple elements

4. Implementation guidelines:

• Write code using TypeScript with proper type annotations
• Include appropriate web-first assertions to validate the action
• Use Playwright's built-in configurations and devices when applicable
• Store frequently used locators in variables for reuse
• Avoid hard-coded wait times - use auto-waiting mechanisms
• Include error handling where appropriate
• Add comments explaining complex logic or non-obvious choices
• For most of the input values try to use js faker library to generate real world like values
• If the test scenario involves navigation to a new page, then do not put any assertions for this new page by assuming the title, page url and locators of the next page which are not shared with you.

5. Code structure:

• Start with necessary imports
• Include test description that clearly states the action being performed
• Break down complex actions into smaller, descriptive test steps
• Use meaningful variable names that reflect their purpose
• Follow Playwright's best practices for test organization

6. Performance and reliability:

• Implement proper waiting strategies using built-in auto-waiting
• Use proper assertion timeouts instead of arbitrary waits
• Include retry logic for flaky operations if necessary
• Consider network conditions and page load states

Respond with only the complete code block and no other text.

Example format:

import { test, expect } from '@playwright/test';

test('descriptive test name', async ({ page }) => {
  // Implementation here
});

This detailed prompt provides comprehensive guidelines for writing high-quality, maintainable UI automation tests using Playwright, covering locator strategies, best practices, code structure, and reliability considerations.