Hogar
generate
alirezarezvani/claude-skills
Generar pruebas de Playwright. Utilizar cuando el usuario diga «escribir pruebas», «generar pruebas», «añadir pruebas para», «probar este componente», «prueba de extremo a extremo», «crear una prueba para», «probar esta página» o «probar esta función».
...Expandir todoAcerca de generate
Esta habilidad, «generate», genera pruebas de extremo a extremo con Playwright listas para producción a partir de una historia de usuario, una URL, una ruta de componente o una descripción de característica. Resuelve el problema de tener que escribir a mano pruebas de navegador fiables y que se ajusten a las convenciones: explora el proyecto existente para conocer su directorio de pruebas, la URL base, los fixtures y las convenciones de los objetos de página antes de generar nada, de modo que el resultado se adapta al código fuente de destino en lugar de a una plantilla genérica.
El flujo de trabajo analiza qué hay que probar, utiliza un subagente «Explore» para leer la configuración de Playwright y las pruebas existentes, selecciona una plantilla adecuada (autenticación, CRUD, proceso de compra, búsqueda, formularios, panel de control, configuración, incorporación, API, accesibilidad) y la adapta con selectores y datos reales. Generate Las pruebas de d siguen estrictas normas de calidad: un orden de prioridad de localizadores que da preferencia a getByRole, getByLabel y otros localizadores semánticos frente al CSS puro; aserciones con reintentos automáticos orientadas a la web; y una prohibición explícita de antipatrones como waitForTimeout, los selectores page.$ y el uso innecesario de page.evaluate. Se ajusta a las convenciones del proyecto en cuanto a TypeScript frente a JavaScript, objetos de página y fixtures, y puede generate admitir objetos de página, fixtures y archivos de datos de prueba cuando sea necesario. Por último, ejecuta las pruebas generate d con la CLI de Playwright y itera en caso de fallos.
Está dirigido a desarrolladores web e ingenieros de control de calidad que utilizan Playwright y desean una cobertura e2e coherente y fácil de mantener, generate d, adaptada al estilo de su propio proyecto. Entre los casos de uso se incluyen las pruebas de flujos de inicio de sesión y de finalización de compra, la validación de formularios, las interfaces de usuario de búsqueda y filtrado, y el comportamiento de los componentes. La skill incluye un archivo SKILL.md y una biblioteca patterns.md con ejemplos concretos de pruebas para flujos de autenticación, CRUD y validación.
Preguntas frecuentes
¿Qué entradas acepta?
Una historia de usuario, la ruta de un archivo de componente, una página o URL, o el nombre de una funcionalidad; por ejemplo, «el usuario puede iniciar sesión con su correo electrónico y contraseña» o «src/components/UserProfile.tsx».
¿Qué estilo de localizadores y aserciones impone?
Da preferencia a los localizadores semánticos (getByRole, getByLabel, getByText, getByPlaceholder, getByTestId, en ese orden) y siempre utiliza aserciones con reintentos automáticos «web-first» en lugar de la extracción manual de texto.
¿Qué antipatrones evita?
Nunca utiliza page.waitForTimeout(), los selectores page.$/page.$$, selectores CSS sin calificadores a menos que sea inevitable, ni page.evaluate() para tareas que pueden realizar los localizadores.
¿Verifica las pruebas que escribe?
Sí: ejecuta la prueba «generate» con «npx playwright test
¿Se ajustará a las convenciones de mi proyecto?
Lee el archivo `playwright.config.ts` y las pruebas existentes para adaptarse a TypeScript o JavaScript, a los objetos de página existentes, a los fixtures personalizados y a los directorios de datos de prueba.
Todos los archivos
2 archivos SKILL.md 4,4 KB Viewpatterns.md 5,7 KB ViewGenerate 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
Descarga y descomprime los archivos de habilidades en tu directorio .claude/skills/.
Descargar ZIPClona el repositorio y copia los archivos de la habilidad a tu proyecto.
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
