Skill webapp-testing: prueba tu tienda con Claude y Playwright

La skill webapp-testing de Anthropic le enseña a Claude Code a probar una web local con Playwright para Python: arranca el servidor, navega, hace capturas y lee el DOM antes de actuar. Sirve para explorar el recorrido de compra de tu tienda y convertir lo que encuentra en un test que corre en cada pull request.

Este tutorial explica qué necesita la skill, cómo instalarla desde el repositorio oficial de skills de Anthropic y cómo llevar el recorrido producto, carrito y checkout a un test de Playwright en tu CI, con una tienda de prueba incluida en la guía. Es la parte 12 de nuestra serie de Claude Code. Lo que corrimos de verdad y lo que no está dicho en cada sección.

Qué es la skill webapp-testing y qué necesita

Una skill es una carpeta con un SKILL.md que Claude lee cuando la tarea encaja con su descripción. La de webapp-testing vive en github.com/anthropics/skills y su descripción dice que sirve para interactuar con aplicaciones web locales y probarlas con Playwright: comprobar el frontend, depurar la interfaz, hacer capturas y leer los logs del navegador.

Lo importante está en sus instrucciones:

• Escribe scripts de Playwright en Python, con sync_playwright() y Chromium en modo headless.
• Trae un ayudante, scripts/with_server.py, que arranca uno o varios servidores, espera a que respondan, corre tu script y los apaga. La skill le pide a Claude que lo ejecute con --help antes de leer su código, para no llenar el contexto.
• Sigue un patrón de reconocimiento y acción: navegar, esperar a networkidle, hacer una captura o leer el DOM, elegir selectores a partir de lo que ve y, después, actuar.

Por eso necesita dos cosas en tu equipo: Python y la librería de Playwright para Python con su navegador.

pip install playwright
playwright install chromium

Una aclaración honesta: en el equipo donde escribimos esta guía no instalamos Playwright para Python, así que no ejecutamos la skill. Lo que sí probamos, y mostramos más abajo, es el resultado al que lleva: el test del recorrido de compra con @playwright/test, en local y listo para CI.

Instalarla desde el marketplace de Anthropic

El repositorio anthropics/skills es también un marketplace de plugins para Claude Code. Dentro de Claude Code:

/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

El marketplace se llama anthropic-agent-skills y tiene varios plugins. webapp-testing va dentro de example-skills, junto a otras once skills:

El propio repositorio avisa de que estas skills son ejemplos con fines de demostración y aprendizaje. Léelas antes de confiarles tu proyecto, como cualquier código que no escribiste. Con el plugin instalado, no hace falta nombrar la skill: basta con pedir una tarea que encaje con su descripción, como «prueba el checkout de mi tienda en localhost».

Explorar el recorrido de compra

El recorrido que importa en una tienda es corto: producto, carrito, checkout. La guía trae una tienda de prueba con exactamente eso, servida con Node y sin dependencias:

Con la skill instalada, el pedido de exploración sería algo así:

Arranca la tienda con "node server.js" en el puerto 4173. Recorre: abre la Camiseta básica,
añádela al carrito, ve al checkout y confirma con el email prueba@example.com. Haz una captura
en cada paso y dime qué selectores usarías para un test.

Según su SKILL.md, al ser una aplicación con JavaScript y sin el servidor arrancado, Claude debería usar with_server.py para levantar la tienda y escribir un script de Python que navega, espera a networkidle, captura cada pantalla y lista botones, enlaces y campos. Eso es la exploración: scripts de usar y tirar que te enseñan cómo es la página por dentro.

Lo que te llevas de ahí son los selectores. Pídelos por rol y texto visible («el botón Añadir al carrito», «el campo Email») y no por clases de CSS o posiciones: un rediseño cambia las clases, pero rara vez cambia lo que lee el cliente.

De la exploración a un test en tu CI

La exploración se tira; el test se queda. El paso que vale la pena es pedirle a Claude que pase lo que encontró a un test de Playwright en el lenguaje de tu proyecto. En un proyecto de JavaScript, eso es @playwright/test:

Este es el test de la tienda de prueba, con los selectores por rol y texto:

// Recorrido de compra en la tienda de prueba: producto, carrito y checkout.
// Usa roles y textos visibles, como los que encuentra la exploración.
import { expect, test } from "@playwright/test";

test("producto, carrito y checkout de prueba", async ({ page }) => {
  await page.goto("/");
  await page.getByRole("link", { name: "Camiseta básica" }).click();

  await page.getByRole("button", { name: "Añadir al carrito" }).click();
  await expect(page.getByRole("status")).toHaveText("Añadido al carrito");
  await expect(page.getByRole("link", { name: "Carrito (1)" })).toBeVisible();

  await page.getByRole("link", { name: "Carrito (1)" }).click();
  await expect(page.getByRole("cell", { name: "Camiseta básica" })).toBeVisible();
  await expect(page.getByRole("cell", { name: "19,99 €" })).toBeVisible();

  await page.getByRole("link", { name: "Ir al checkout" }).click();
  await page.getByLabel("Email").fill("prueba@example.com");
  await page.getByRole("button", { name: "Confirmar pedido de prueba" }).click();

  await expect(page.getByRole("heading", { name: "Pedido de prueba confirmado" })).toBeVisible();
  await expect(page.getByRole("link", { name: "Carrito (0)" })).toBeVisible();
});

test("el carrito vacío no deja ir al checkout", async ({ page }) => {
  await page.goto("/carrito.html");
  await expect(page.getByText("Tu carrito está vacío.")).toBeVisible();
  await expect(page.getByRole("link", { name: "Ir al checkout" })).toBeHidden();
});

La configuración arranca la tienda antes de los tests con webServer, igual que with_server.py lo hacía en la exploración:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "tests",
  retries: process.env.CI ? 1 : 0,
  use: { baseURL: "http://localhost:4173", trace: "on-first-retry" },
  // Playwright arranca la tienda antes de los tests y la para al terminar.
  webServer: { command: "node server.js", url: "http://localhost:4173", reuseExistingServer: !process.env.CI },
  projects: [{ name: "chromium", use: { ...devices["Desktop Chrome"] } }],
});

Lo corrimos en local con Playwright 1.62: los dos tests pasaron. Para comprobar que el test sirve de algo, rompimos la tienda a propósito, quitando la línea que vacía el carrito después de confirmar el pedido. El test lo detectó:

Con la línea restaurada, los dos tests volvieron a pasar. Para que esto corra en cada pull request, el workflow de la guía instala Chromium en el runner y ejecuta los tests:

# Corre el recorrido de compra con Playwright en cada PR y en cada push a main.
name: E2E

on:
  pull_request:
  push:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test

El YAML está validado, pero no lo corrimos en GitHub para esta guía. Si quieres que Claude además explique los fallos en el log, combínalo con el paso de la parte 9 de la serie.

Límites: datos de prueba, pagos y tiendas en producción

• Datos de prueba. Usa emails y direcciones inventados, como prueba@example.com. Nunca datos de clientes reales, ni en el test ni en las capturas de la exploración.
• Pagos. El test no debe cobrar nada. En una tienda propia, usa el modo de prueba de tu pasarela. En Shopify, las tiendas de desarrollo permiten pedidos de prueba con la pasarela de pruebas (Bogus Gateway) o con el modo de prueba de Shopify Payments.
• Nunca contra producción. Un test de compra en la tienda real crea pedidos, descuenta inventario, manda emails al equipo y ensucia tu analítica. Apúntalo a localhost, a un entorno de preview o a una tienda de desarrollo.
• Contraseña de la tienda. Las tiendas de desarrollo de Shopify suelen estar protegidas con contraseña; el test tiene que pasar esa pantalla primero, con la contraseña en un secreto del CI.
• Lo que el test no ve. Comprueba que el recorrido funciona, no que los precios sean los correctos para cada mercado ni que los impuestos estén bien. Para eso hacen falta tests propios.

Errores comunes

• Guardar los scripts de exploración como tests. Esperas fijas y capturas sirven para mirar, no para CI. Pasa la exploración a @playwright/test.
• Selectores por clase o posición. .btn-primary:nth-child(2) se rompe con el primer rediseño. Usa rol y texto.
• Inspeccionar antes de que cargue la página. La propia skill avisa: en una aplicación con JavaScript, espera a networkidle antes de leer el DOM.
• Olvidar arrancar el servidor en CI. Sin webServer en la configuración, el test falla por conexión, no por tu código.
• Apuntar a la tienda real «solo una vez». Esa vez queda un pedido de verdad.
• Instalar todas las skills sin leerlas. El plugin trae doce; instálalo sabiendo qué hace cada una.

Preguntas frecuentes

¿Necesito Python si mi proyecto es de JavaScript?

Para la skill, sí: sus scripts de exploración son de Python. El test que guardas puede ser del lenguaje de tu proyecto, como el de esta guía con @playwright/test.

¿En qué se diferencia de los agentes de Playwright?

Los agentes de Playwright son subagentes que planifican, generan y reparan tests dentro de un proyecto que ya usa @playwright/test. La skill es más ligera: le da a Claude un método para explorar cualquier web local. Los agentes están en agentes de Playwright con Claude Code.

¿Sirve con un tema de Shopify en local?

Sí, si el tema corre en local con shopify theme dev: la skill puede arrancar ese servidor con with_server.py y explorar el preview. El checkout de Shopify no corre en local, así que el tramo de pago se prueba en una tienda de desarrollo.

¿Cuántos tests de compra hacen falta?

Pocos y estables. Uno por recorrido crítico (compra simple, con cupón, con carrito vacío) atrapa más fallos reales que cincuenta tests frágiles. Antes de una fecha fuerte, el smoke test del checkout es el mínimo.

¿Puede Claude arreglar el test cuando falla?

Puede proponer el arreglo, pero decide tú si el que está mal es el test o la tienda. En nuestra prueba, el test falló porque la tienda estaba rota, que es justo lo que tenía que hacer.

Checklist

• Python y Playwright para Python están instalados, si vas a usar la skill.
• El plugin example-skills está instalado y leíste el SKILL.md de webapp-testing.
• La exploración se hace contra localhost o una tienda de desarrollo, nunca producción.
• El test usa selectores por rol y texto visible.
• Los datos del test son inventados y el pago es de prueba o no existe.
• El test corre en CI en cada pull request y falla si rompes el checkout a propósito.

La skill acelera la parte de mirar la página; el valor está en el test que queda. Para que ese test llegue con un plan detrás, empieza en plan mode; para que corra y se explique en tu pipeline, sigue con Claude Code en GitHub Actions; y para una segunda lectura del código, el subagente revisor. El método completo está en mi flujo de 4 pasos con Claude Code.

¿Viste esto en Instagram? Comenta TEST en el Reel o el carrusel y te mando la guía.