generate
alirezarezvani/claude-skills
Gerar testes com Playwright. Use este recurso quando o usuário solicitar “escrever testes”, “gerar testes”, “adicionar testes para”, “testar este componente”, “teste E2E”, “criar teste para”, “testar esta página” ou “testar este recurso”.
...Expandir tudoSobre a funcionalidade de geração
Essa habilidade gera testes end-to-end do Playwright prontos para uso a partir de uma história de usuário, URL, caminho de componente ou descrição de funcionalidade. Ela resolve o problema de se escrever testes de navegador confiáveis e alinhados a convenções manualmente: ela analisa o projeto existente para identificar seu diretório de testes, URL base, fixtures e convenções de objetos de página antes de gerar qualquer coisa, de modo que a saída se adapte ao código-fonte-alvo e não a um modelo genérico.
O fluxo de trabalho analisa o que deve ser testado, utiliza um subagente chamado Explore para ler a configuração do Playwright e os testes existentes, seleciona um modelo adequado (autenticação, CRUD, finalização de compra, busca, formulários, painel de controle, configurações, onboarding, API, acessibilidade) e o adapta com seletores e dados reais. Os testes gerados seguem regras rígidas de qualidade: uma ordem de prioridade nos locadores que dá preferência a getByRole, getByLabel e outros locadores semânticos em vez de seletores CSS puros; afirmações que tentam automaticamente novamente se o acesso à página falhar; e proibição explícita de padrões antipáticos como waitForTimeout, seletores page.$ e page.evaluate() desnecessários. Ela se adapta às convenções do projeto em relação a TypeScript versus JavaScript, objetos de página e fixtures, e pode gerar objetos de página auxiliares, fixtures e arquivos de dados de teste quando necessário. Por fim, ela executa os testes gerados com o Playwright CLI e corrige os falhos encontrados.
É voltada para desenvolvedores web e engenheiros de QA que utilizam o Playwright e desejam obter cobertura end-to-end consistente e fácil de manter, no estilo do próprio projeto. Os casos de uso incluem testes de fluxos de login e finalização de compra, validação de formulários, interfaces de busca e filtragem e comportamento de componentes. A habilidade vem acompanhada de um arquivo SKILL.md e de uma biblioteca patterns.md com exemplos concretos de testes para fluxos de autenticação, CRUD e validação.
Perguntas frequentes
Quais entradas ela aceita?
Uma história de usuário, um caminho de arquivo de componente, uma página ou URL, ou o nome de uma funcionalidade — por exemplo, “o usuário pode fazer login com e-mail e senha” ou “src/components/UserProfile.tsx”.
Que estilo de locador e afirmação ela impõe?
Ela prefere locadores semânticos (getByRole, getByLabel, getByText, getByPlaceholder, getByTestId nessa ordem) e sempre utiliza afirmações que tentam automaticamente novamente se o acesso à página falhar, em vez de extração manual de texto.
Quais padrões antipáticos ela evita?
Ela nunca utiliza page.waitForTimeout(), seletores page.$/page.$$ ou seletores CSS puros, a menos que seja inevitável, nem page.evaluate() para tarefas que podem ser realizadas por locadores.
Ela verifica os testes que gera?
Sim — ela executa o teste gerado com “npx playwright test
Ela se adapta às convenções do meu projeto?
Ela lê o arquivo playwright.config.ts e os testes existentes para se adaptar a TypeScript versus JavaScript, objetos de página já existentes, fixtures personalizados e diretórios de dados de teste.
Todos os arquivos
2 arquivosSKILL.md4,4 KBVisualizarpatterns.md5,7 KBVisualizar
Generate production-ready Playwright tests from a user story, URL, component name, or feature description.
Input
$ARGUMENTS contains what to test. Examples:
"user can log in with email and password""the checkout flow""src/components/UserProfile.tsx""the search page with filters"
Steps
1. Understand the Target
Parse $ARGUMENTS to determine:
- User story: Extract the behavior to verify
- Component path: Read the component source code
- Page/URL: Identify the route and its elements
- Feature name: Map to relevant app areas
2. Explore the Codebase
Use the Explore subagent to gather context:
- Read
playwright.config.tsfortestDir,baseURL,projects - Check existing tests in
testDirfor patterns, fixtures, and conventions - If a component path is given, read the component to understand its props, states, and interactions
- Check for existing page objects in
pages/ - Check for existing fixtures in
fixtures/ - Check for auth setup (
auth.setup.tsorstorageStateconfig)
3. Select Templates
Check templates/ in this plugin for matching patterns:
| If testing... | Load template from |
|---|---|
| Login/auth flow | ../pw/templates/auth/login.md |
| CRUD operations | templates/crud/ |
| Checkout/payment | templates/checkout/ |
| Search/filter UI | templates/search/ |
| Form submission | templates/forms/ |
| Dashboard/data | templates/dashboard/ |
| Settings page | templates/settings/ |
| Onboarding flow | templates/onboarding/ |
| API endpoints | templates/api/ |
| Accessibility | templates/accessibility/ |
Adapt the template to the specific app — replace {{placeholders}} with actual selectors, URLs, and data.
4. Generate the Test
Follow these rules:
Structure:
import { test, expect } from '@playwright/test';// Import custom fixtures if the project uses themtest.describe('Feature Name', () => { // Group related behaviors test('should <expected behavior>', async ({ page }) => { // Arrange: navigate, set up state // Act: perform user action // Assert: verify outcome });});
Locator priority (use the first that works):
getByRole()— buttons, links, headings, form elementsgetByLabel()— form fields with labelsgetByText()— non-interactive text contentgetByPlaceholder()— inputs with placeholder textgetByTestId()— when semantic options aren't available
Assertions — always web-first:
// GOOD — auto-retriesawait expect(page.getByRole('heading')).toBeVisible();await expect(page.getByRole('alert')).toHaveText('Success');// BAD — no retryconst text = await page.textContent('.msg');expect(text).toBe('Success');
Never use:
page.waitForTimeout()page.$(selector)orpage.$$(selector)- Bare CSS selectors unless absolutely necessary
page.evaluate()for things locators can do
Always include:
- Descriptive test names that explain the behavior
- Error/edge case tests alongside happy path
- Proper
awaiton every Playwright call baseURL-relative navigation (page.goto('/')notpage.goto('http://...'))
5. Match Project Conventions
- If project uses TypeScript → generate
.spec.ts - If project uses JavaScript → generate
.spec.jswithrequire()imports - If project has page objects → use them instead of inline locators
- If project has custom fixtures → import and use them
- If project has a test data directory → create test data files there
6. Generate Supporting Files (If Needed)
- Page object: If the test touches 5+ unique locators on one page, create a page object
- Fixture: If the test needs shared setup (auth, data), create or extend a fixture
- Test data: If the test uses structured data, create a JSON file in
test-data/
7. Verify
Run the generated test:
npx playwright test <generated-file> --reporter=list
If it fails:
- Read the error
- Fix the test (not the app)
- Run again
- If it's an app issue, report it to the user
Output
- Generated test file(s) with path
- Any supporting files created (page objects, fixtures, data)
- Test run result
- Coverage note: what behaviors are now tested
Instalar generate
Baixe e extraia os arquivos de habilidades para o seu diretório .claude/skills/.
Baixar ZIPClone o repositório e copie os arquivos da habilidade para o seu projeto.
git clone https://github.com/alirezarezvani/claude-skills/blob/main/engineering-team/playwright-pro/skills/generate/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copiar





Lar
