Option
HeimHeim Skill Browser-Automatisierung frontend-testing-best-practices

frontend-testing-best-practices

sergiodxa/agent-skills sergiodxa/agent-skills

Testen von Best Practices für die Frontend-Entwicklung. Dabei wird der Schwerpunkt auf E2E-Tests statt auf Unit-Tests gelegt, es wird auf ein Minimum an Mocking gesetzt, und es werden das Verhalten im Vergleich zu Implementierungsdetails getestet. Verwenden Sie diese Richtlinien beim Schreiben von Tests oder bei der Überprüfung von Testcode.

...Alle erweitern
53
Zeit aktualisiert 7. Juli 2026

Über frontend-testing-best-practices

Die Fähigkeit „frontend-testing-best-practices“ bietet umfassende Leitlinien zur Erstellung effektiver und wartbarer Tests für Frontend-Anwendungen. Sie befasst sich mit dem häufigen Problem von Tests, die anfällig sind, schwer zu warten und durch den Fokus auf Implementierungsdetails statt auf Benutzerverhalten eine falsche Sicherheit vermitteln. Dabei wird eine Philosophie betont, bei der End-to-End-Tests Vorrang vor Unit-Tests haben, Mocks möglichst sparsam eingesetzt werden und stattdessen das Verhalten getestet wird anstatt die Implementierungsdetails.

Diese Fähigkeit umfasst 6 Kernregeln, die in drei Kategorien unterteilt sind: Teststrategie (kritischer Grad), End-to-End-Tests (hohe Priorität) sowie Unit-Tests (mittlere Priorität). Zu den wichtigsten Inhalten gehören Anleitungen dazu, wann End-to-End-Tests gegenüber Unit-Tests sinnvoll sind, wie End-to-End-Tests in der richtigen Verzeichnisstruktur organisiert werden sollten, Best Practices für die Verwendung zugänglicher Selektoren in Playwright-Tests, das Vermeiden von Unit-Tests für React-Komponenten sowie das Halten von Mocks einfach. Die Regeln enthalten praktische Codebeispiele, die gute und schlechte Vorgehensweisen vergleichen, um die Leitlinien unmittelbar anwendbar zu machen.

Diese Fähigkeit eignet sich ideal für Frontend-Entwickler, die an Webanwendungen arbeiten und Entscheidungen bezüglich der Testsicherung treffen müssen, neue Tests schreiben oder Testcode überprüfen. Sie ist besonders wertvoll für Teams, die Playwright für End-to-End-Tests sowie React für UI-Komponenten verwenden. Nutzen Sie diese Fähigkeit bei der Entscheidung, welche Art von Test geschrieben werden soll, bei der Einführung neuer Testabdeckungen, beim Refactoring bestehender Tests oder bei Code-Reviews von Testdateien. Die Leitlinien helfen Teams dabei, gängige Anti-Muster in der Testsicherung zu vermeiden und Test-Suiten zu erstellen, die eine echte Sicherheit bezüglich des Anwendungsverhaltens bieten.

FAQ

Wann sollte ich Unit-Tests statt End-to-End-Tests schreiben?

Verwenden Sie für die meisten Szenarien standardmäßig End-to-End-Tests. Schreiben Sie nur Unit-Tests für reine Funktionen, die keine Abhängigkeiten haben und isolierte Logiken wie Datenformatierung oder Berechnungen ausführen. Wenn Sie etwas testen, das React-Komponenten, API-Aufrufe oder Benutzerinteraktionen beinhaltet, sollten Sie stattdessen einen End-to-End-Test erstellen.

Welches Testframework setzt diese Fähigkeit voraus?

In den Beispielen für End-to-End-Tests wird Playwright verwendet, und für das Mocking von APIs wird auf MSW (Mock Service Worker) verwiesen. Die Beispiele zu React-Komponenten deuten auf eine JavaScript/TypeScript-basierte Frontend-Stack hin, doch die grundlegenden Prinzipien gelten für jedes Frontend-Framework.

Wie viele Mocks sind in einem Test bereits zu viele?

Wenn Sie in einem einzigen Test 3 oder mehr Mocks benötigen, ist das ein Zeichen dafür, stattdessen einen End-to-End-Test zu schreiben. Einfache Mocks (wie ein einzelner MSW-Handler für eine API-Endpunkt) sind in Ordnung, doch komplexe Mock-Einrichtungen deuten darauf hin, dass Sie das tatsächlich integrierte System testen sollten.

Wo sollten End-to-End-Tests im Projekt platziert werden?

End-to-End-Tests sollten im Verzeichnis e2e/tests/ am Projektroot liegen und nicht innerhalb des Verzeichnisses frontend/. Dadurch bleiben sie getrennt von den Unit-Tests und wird deutlich, dass sie das gesamte System testen.

Welche Selektormethode sollte ich in Playwright-Tests verwenden?

Befolgen Sie folgende Priorität: Selektoren auf Basis von Rollen (getByRole) sind vorzuziehen, danach solche auf Basis von Labels (getByLabel), anschließend der Textinhalt – und schließlich nur Test-ID-Selktoren (getByTestId), wenn es keinen zugänglichen Selektor gibt. Vermeiden Sie CSS-Selktoren, da sie anfällig sind und nicht das Verhalten widerspiegeln, wie Benutzer mit der Anwendung interagieren.

Auf GitHub ansehen

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

  1. Prefer E2E tests over unit tests - Test the whole system, not isolated pieces
  2. Minimize mocking - If you need complex mocks, write an E2E test instead
  3. Test behavior, not implementation - Test what users see and do
  4. 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 utilities
  • vitest.config.ts - Unit test configuration
  • vitest.setup.ts - Global test setup with MSW
  • app/utils/test-utils.ts - Unit test utilities

frontend-testing-best-practices installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihren Ordner .claude/skills/.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

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

Kopieren Kopieren
Schnelle Einrichtung: Kopieren Sie den Skill-Ordner in .claude/skills/. Claude wird ihn automatisch erkennen und verwenden.

Ähnliche Skills

playwright-cli
Zeit aktualisiert 29. Juni 2026
Playwright Browser Automation
Zeit aktualisiert 29. Juni 2026
playwright-generate-test
Zeit aktualisiert 29. Juni 2026
playwright-expert
Zeit aktualisiert 29. Juni 2026
OR