Generate Playwright TypeScript Tests for a Feature
Generate a complete Playwright TypeScript test file for a given feature, covering positive, negative, and edge cases with role-based locators and no hard waits.
playwrighttypescripte2eautomationtest-generation
prompt template
You are a senior QA automation engineer with deep expertise in Playwright and TypeScript. Before writing any code, briefly state your assumptions about the feature, then generate a Playwright TypeScript test file. Feature to test: {{FEATURE_NAME}} Application URL: {{APP_URL}} User roles involved: {{USER_ROLES}} Acceptance criteria: {{ACCEPTANCE_CRITERIA}} Test data available: {{TEST_DATA}} Known selectors or data-testid attributes (leave blank if unknown): {{KNOWN_SELECTORS}} Requirements for the generated tests: - Use role-based locators (getByRole, getByLabel, getByText) as the first choice; use data-testid attributes as the second choice; avoid CSS class or XPath selectors. - Cover at minimum: positive (happy path), negative (invalid input / unauthorised access), and edge cases (boundary values, empty states, concurrent actions if relevant). - Do NOT use hard waits (page.waitForTimeout). Use Playwright auto-waiting and explicit expect assertions instead. - Each test must have a clear, human-readable name describing what it verifies and what the expected outcome is. - Group related tests using describe blocks named after the acceptance criteria or user role they cover. - Extract repeated selectors and test data into constants at the top of the file. - Add a short comment above each test explaining what scenario it covers and why it matters (one line only). - If you have to guess at a selector because {{KNOWN_SELECTORS}} is empty, call it out with a TODO comment so a human can verify it. Output format: 1. A brief "Assumptions" section listing anything you inferred that the team should verify. 2. The complete TypeScript test file, ready to save as a .spec.ts file.
{{FEATURE_NAME}}requiredShort name of the feature being tested
e.g. User login with email and password
{{APP_URL}}requiredThe URL of the page or feature under test
e.g. https://staging.example.com/login
{{USER_ROLES}}requiredComma-separated list of user roles relevant to this feature
e.g. admin, standard user, guest
{{ACCEPTANCE_CRITERIA}}requiredThe acceptance criteria for this feature, ideally as a numbered list
e.g. 1. User can log in with valid email and password 2. User sees an error message for invalid credentials 3. Admin users are redirected to /dashboard, standard users to /home
{{TEST_DATA}}Sample test data — use fake/synthetic values, never real credentials or PII
e.g. Valid: user@example.com / Pass123! Invalid: notauser@example.com / wrongpass Admin: admin@example.com / Admin123!
{{KNOWN_SELECTORS}}Any data-testid attributes or ARIA roles you know are present in the UI
e.g. data-testid="login-email", data-testid="login-password", data-testid="login-submit"
- Verify every selector/data-testid in the generated code exists in the actual UI — AI will invent them if KNOWN_SELECTORS is empty.
- Check that the test data uses synthetic values only — no real credentials, emails, or PII were accidentally included.
- Confirm the redirect URLs match your environment's actual routing.
- Run `npx tsc --noEmit` on the generated file to catch type errors before executing.
- Execute the tests against a real staging environment, not just a code review — Playwright tests must be run to be trusted.
- Review the Assumptions section the AI generated and resolve every open question before merging.
- Check negative tests actually assert the error message text — not just that a URL change did not occur.
- Ensure no `page.waitForTimeout` slipped into the output; replace any found with `expect` assertions.
AI output requires human review before use. These checks are your responsibility.
⚠ Illustrative only — not a guarantee of output quality. Always review AI output before use.
Example output
// NOTE: This is an illustrative draft. Selectors and flow must be verified against the actual UI before use.
// Assumptions:
// 1. The login form is at /login; POST redirects to /dashboard (admin) or /home (standard user).
// 2. Error messages appear inline, not in a toast — verify this.
// 3. No CAPTCHA on the staging environment — confirm before running in CI.
import { test, expect } from '@playwright/test';
const SELECTORS = {
emailInput: 'input[data-testid="login-email"]', // TODO: verify data-testid
passwordInput: 'input[data-testid="login-password"]',
submitButton: 'button[data-testid="login-submit"]',
errorMessage: '[data-testid="login-error"]',
};
const USERS = {
admin: { email: 'admin@example.com', password: 'Admin123!' },
standard: { email: 'user@example.com', password: 'Pass123!' },
invalid: { email: 'notauser@example.com', password: 'wrongpass' },
};
test.describe('Login — happy path', () => {
// Verifies that a standard user can authenticate and reaches the correct landing page
test('standard user logs in and reaches /home', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill(USERS.standard.email);
await page.getByLabel('Password').fill(USERS.standard.password);
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page).toHaveURL('/home');
});
});- Add Page Object Model classes for the login page and redirect targets.
- Generate a fixture file for the test users defined in the test data above.
- Convert these tests to use Playwright's built-in auth state storage so login runs once per test suite.
- Identify which of these tests are strong candidates for visual regression testing with Percy or Applitools.
- AI will invent plausible-looking selectors when KNOWN_SELECTORS is empty — they will fail at runtime.
- Generated test data may accidentally mirror patterns that look like real credentials — review before committing.
- The AI may miss role-specific redirect logic if ACCEPTANCE_CRITERIA does not spell it out explicitly.
- Negative tests may be shallow (checking a URL did not change) rather than asserting specific error messages.
- If the feature has complex async state (WebSockets, polling), the AI is likely to miss appropriate wait strategies.
- The generated code compiles but does not guarantee correct behaviour — human review and execution are mandatory.
Tools:PlaywrightGlossary:Negative TestingValidationHallucination