frontend-testing-best-practices
sergiodxa/agent-skills
Testar as melhores práticas para o front-end. Dar ênfase aos testes E2E em vez de testes unitários, utilizar o mínimo de simulação e focar no comportamento do sistema em vez dos detalhes da implementação. Utilizar isso ao escrever testes ou revisar o código de teste.
...Expandir tudoSobre as Melhores Práticas de Teste Frontend
A habilidade “Melhores Práticas de Teste Frontend” fornece diretrizes abrangentes para escrever testes eficazes e mantíveis para aplicações frontend. Ela aborda o problema comum de escrever testes que são frágeis, difíceis de manter e que geram uma falsa sensação de confiança, ao se concentrarem em detalhes de implementação em vez do comportamento do usuário. Esta habilidade enfatiza uma filosofia que prioriza os testes end-to-end em detrimento dos testes unitários, o uso mínimo de mocks e o teste do comportamento em vez dos detalhes de implementação.
A habilidade contém 6 regras principais organizadas em três categorias: Estratégia de Teste (nível crítico), Testes End-to-End (alta prioridade) e Testes Unitários (média prioridade). As capacidades-chave incluem orientações sobre quando escrever testes end-to-end ou unitários, como estruturar os testes end-to-end no diretório correto, melhores práticas para o uso de seletores acessíveis em testes com Playwright, evitar testes unitários de componentes React e manter os mocks simples. As regras utilizam exemplos práticos de código para comparar abordagens boas e ruins, tornando as diretrizes imediatamente aplicáveis.
Esta habilidade é ideal para desenvolvedores frontend que trabalham em aplicações web e precisam tomar decisões sobre testes, escrever novos testes ou revisar o código de teste. É particularmente valiosa para equipes que utilizam Playwright para testes end-to-end e React para componentes UI. Use esta habilidade ao decidir qual tipo de teste escrever, implementar nova cobertura de teste, refatorar testes existentes ou realizar revisões de código de arquivos de teste. As diretrizes ajudam as equipes a evitar padrões antigos de teste e a criar conjuntos de testes que forneçam uma verdadeira confiança no comportamento da aplicação.
Perguntas Frequentes
Quando devo escrever testes unitários em vez de testes end-to-end?
Por padrão, use testes end-to-end para a maioria das situações. Escreva testes unitários apenas para funções puras que não têm dependências e realizam lógicas isoladas, como formatação de dados ou cálculos. Se você estiver testando algo que envolve componentes React, chamadas de API ou interações do usuário, escreva um teste end-to-end.
Qual framework de teste esta habilidade assume?
A habilidade usa Playwright para exemplos de testes end-to-end e faz referência ao MSW (Mock Service Worker) para o mocking de APIs. Os exemplos de componentes React sugerem uma pilha frontend em JavaScript/TypeScript, mas os princípios fundamentais se aplicam a qualquer framework frontend.
Quantos mocks são demais em um teste?
Se você precisar de 3 ou mais mocks em um único teste, isso é um sinal de que deve escrever um teste end-to-end. Mocks simples (como um único manipulador MSW para um ponto final de API) são aceitáveis, mas configurações de mocks complexas indicam que você deve testar o sistema integrado real.
Onde os testes end-to-end devem ser localizados no projeto?
Os testes end-to-end devem ser colocados no diretório e2e/tests/, na raiz do projeto, e não dentro do diretório frontend/. Isso os separa dos testes unitários e torna claro que eles testam o sistema inteiro.
Qual estratégia de seletores devo usar em testes com Playwright?
Seguindo esta prioridade: seletores baseados em papel (getByRole) são preferidos, depois aqueles baseados em rótulo (getByLabel), seguidos pelo conteúdo do texto e, por último, IDs de teste (getByTestId) apenas quando nenhum seletor acessível estiver disponível. Evite seletores CSS, pois eles são frágeis e não refletem como os usuários interagem com a aplicação.
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 os arquivos
7 arquivosInstalar frontend-testing-best-practices
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/sergiodxa/agent-skills/blob/main/skills/frontend-testing-best-practices/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copiar





Lar
