frontend-testing-best-practices
sergiodxa/agent-skills
Prueba de las mejores prácticas para el frontend. Se da prioridad a las pruebas E2E sobre las pruebas unitarias, se recomienda utilizar un mínimo de simulaciones y se enfatiza la verificación del comportamiento en lugar de los detalles de implementación. Úsela al escribir pruebas o al revisar código de pruebas.
...Expandir todoAcerca de frontend-testing-best-practices
La habilidad frontend-testing-best-practices ofrece directrices completas para crear pruebas eficaces y fáciles de mantener para aplicaciones front-end. Aborda el problema común de desarrollar pruebas frágiles, difíciles de mantener y que generan una confianza falsa al centrarse en detalles de implementación en lugar del comportamiento del usuario. Esta habilidad promueve una filosofía que da prioridad a las pruebas end-to-end (E2E) sobre las pruebas unitarias, recomienda un uso mínimo de simulaciones y enfatiza la prueba del comportamiento en lugar de los detalles técnicos.
Dicha habilidad incluye 6 reglas fundamentales organizadas en tres categorías: Estrategia de pruebas (nivel crítico), Pruebas E2E (alta prioridad) y Pruebas unitarias (prioridad media). Entre las capacidades clave se encuentran indicaciones sobre cuándo escribir pruebas E2E frente a pruebas unitarias, cómo estructurar las pruebas E2E en el directorio adecuado, buenas prácticas para utilizar selectores accesibles en pruebas con Playwright, cómo evitar pruebas unitarias de componentes React y cómo mantener las simulaciones simples. Las reglas incluyen ejemplos de código prácticos que comparan enfoques correctos e incorrectos, lo que permite aplicar estas directrices de inmediato.
Esta habilidad es ideal para desarrolladores front-end que trabajan en aplicaciones web y necesitan tomar decisiones relacionadas con las pruebas, crear nuevas pruebas o revisar código de pruebas. Es especialmente valiosa para equipos que utilizan Playwright para pruebas E2E y React para componentes de interfaz de usuario. Úsela al decidir qué tipo de pruebas escribir, al implementar nueva cobertura de pruebas, al refactorizar pruebas existentes o al realizar revisiones de código en archivos de pruebas. Las directrices ayudan a los equipos a evitar patrones antiétnicos comunes en las pruebas y a crear conjuntos de pruebas que ofrezcan una confianza real respecto al comportamiento de la aplicación.
Preguntas frecuentes
¿Cuándo debería escribir pruebas unitarias frente a pruebas E2E?
Para la mayoría de los casos, opte por pruebas E2E. Solo escriba pruebas unitarias para funciones puras que no tengan dependencias y que realicen lógica aislada como el formato de datos o cálculos. Si está probando algo que involucre componentes React, llamadas a API o interacciones con el usuario, escriba una prueba E2E en su lugar.
¿Qué framework de pruebas asume esta habilidad?
La habilidad utiliza Playwright como ejemplo para pruebas E2E y hace referencia a MSW (Mock Service Worker) para la simulación de APIs. Los ejemplos relacionados con componentes React sugieren un stack front-end basado en JavaScript/TypeScript, pero los principios fundamentales son aplicables a cualquier framework front-end.
¿Cuántas simulaciones son demasiadas en una prueba?
Si necesita 3 o más simulaciones en una sola prueba, eso es una señal de que debería escribir una prueba E2E en su lugar. Las simulaciones simples (como un único manejador MSW para un punto final de API) están bien, pero configuraciones complejas indican que debe probar el sistema integrado real.
¿Dónde deben colocarse las pruebas E2E en el proyecto?
Las pruebas E2E deben ubicarse en el directorio e2e/tests/ en la raíz del proyecto, y no dentro del directorio frontend/. Esto las mantiene separadas de las pruebas unitarias y deja claro que prueban todo el sistema.
¿Qué estrategia de selectores debería utilizar en pruebas con Playwright?
Siga este orden de prioridad: se prefieren los selectores basados en roles (getByRole), seguidos por aquellos basados en etiquetas (getByLabel), luego por el contenido del texto, y finalmente solo se deben usar los IDs de prueba (getByTestId) cuando no exista ningún selector accesible. Evite los selectores CSS, ya que son frágiles y no reflejan cómo interactúan los usuarios con la aplicación.
Testing Best Practices
Guidelines for writing effective, maintainable tests that provide real confidence. Contains 6 rules focused on preferring E2E tests, minimizing mocking, and testing behavior over implementation.
Core Philosophy
- Prefer E2E tests over unit tests - Test the whole system, not isolated pieces
- Minimize mocking - If you need complex mocks, write an E2E test instead
- Test behavior, not implementation - Test what users see and do
- Avoid testing React components directly - Test them through E2E
When to Apply
Reference these guidelines when:
- Deciding what type of test to write
- Writing new E2E or unit tests
- Reviewing test code
- Refactoring tests
Rules Summary
Testing Strategy (CRITICAL)
prefer-e2e-tests - @rules/prefer-e2e-tests.md
Default to E2E tests. Only write unit tests for pure functions.
// E2E test (PREFERRED) - tests real user flowtest("user can place an order", async ({ page }) => { await createTestingAccount(page, { account_status: "active" }); await page.goto("/catalog"); await page.getByRole("heading", { name: "Example Item" }).click(); await page.getByRole("link", { name: "Buy" }).click(); // ... complete flow await expect(page.getByAltText("Thank you")).toBeVisible();});// Unit test - ONLY for pure functionstest("formatCurrency formats with two decimals", () => { expect(formatCurrency(1234.5)).toBe("$1,234.50");});
avoid-component-tests - @rules/avoid-component-tests.md
Don't unit test React components. Test them through E2E or not at all.
// BAD: Component unit testdescribe("OrderCard", () => { test("renders amount", () => { render(<OrderCard amount={100} />); expect(screen.getByText("$100")).toBeInTheDocument(); });});// GOOD: E2E test covers the component naturallytest("order history shows orders", async ({ page }) => { await page.goto("/orders"); await expect(page.getByText("$100")).toBeVisible();});
minimize-mocking - @rules/minimize-mocking.md
Keep mocks simple. If you need 3+ mocks, write an E2E test instead.
// BAD: Too many mocks = write E2E testvi.mock("~/lib/auth");vi.mock("~/lib/transactions");vi.mock("~/hooks/useAccount");// GOOD: Simple MSW mock for loader testmockServer.use( http.get("/api/user", () => HttpResponse.json({ name: "John" })),);
E2E Tests (HIGH)
e2e-test-structure - @rules/e2e-test-structure.md
E2E tests go in e2e/tests/, not frontend/.
// e2e/tests/order.spec.tsimport { test, expect } from "@playwright/test";import { addAccountBalance, createTestingAccount } from "./utils";test.describe("Orders", () => { test.beforeEach(async ({ page, context }) => { await createTestingAccount(page, { account_status: "active" }); let cookies = await context.cookies(); let account_id = cookies.find((c) => c.name === "account_id").value; await addAccountBalance({ account_id, amount: 10000, replaceBalance: true }); }); test("place order with default values", async ({ page }) => { await page.goto("/catalog"); // ... user flow });});
e2e-selectors - @rules/e2e-selectors.md
Use accessible selectors: role > label > text > testid.
// GOOD: Role-based (preferred)await page.getByRole("button", { name: "Submit" }).click();await page.getByRole("heading", { name: "Dashboard" });// GOOD: Label-basedawait page.getByLabel("Email").fill("[email protected]");// OK: Test ID when no accessible selector existsawait expect(page.getByTestId("balance")).toHaveText("$1,234");// BAD: CSS selectorsawait page.locator(".btn-primary").click();
Unit Tests (MEDIUM)
unit-test-structure - @rules/unit-test-structure.md
Unit tests for pure functions only. Co-locate with source files.
// app/utils/format.test.tsimport { describe, test, expect } from "vitest";import { formatCurrency } from "./format";describe("formatCurrency", () => { test("formats positive amounts", () => { expect(formatCurrency(1234.5)).toBe("$1,234.50"); }); test("handles zero", () => { expect(formatCurrency(0)).toBe("$0.00"); });});
Key Files
e2e/tests/- E2E tests (Playwright)e2e/tests/utils.ts- E2E test utilitiesvitest.config.ts- Unit test configurationvitest.setup.ts- Global test setup with MSWapp/utils/test-utils.ts- Unit test utilities
Todos los archivos
7 archivosInstalar frontend-testing-best-practices
Descargue y extraiga los archivos de habilidades a su directorio .claude/skills/.
Descargar ZIPClona el repositorio y copia los archivos de la habilidad a tu proyecto.
git clone https://github.com/sergiodxa/agent-skills/blob/main/skills/frontend-testing-best-practices/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copiar





Hogar
