Maison
frontend-testing-best-practices
sergiodxa/agent-skills
Meilleures pratiques en matière de tests pour le front-end. Privilégie les tests de bout en bout (E2E) plutôt que les tests unitaires, un recours minimal aux simulateurs (mocking) et la vérification du comportement plutôt que des détails d'implémentation. À utiliser lors de la rédaction de tests ou de la révision du code de test.
...Développer toutÀ propos frontend-testing-best-practices
La compétence « frontend-testing-best-practices » fournit des directives complètes pour écrire des tests efficaces et faciles à maintenir pour les applications front-end. Elle aborde le problème courant des tests fragiles, difficiles à maintenir et qui donnent une fausse impression de sécurité en se concentrant sur les détails d’implémentation plutôt que sur le comportement de l’utilisateur. Cette compétence met en avant une philosophie qui privilégie les tests de bout en bout (E2E) par rapport aux tests unitaires, un recours minimal aux simulacres, et le test du comportement plutôt que des détails d’implémentation.
Cette compétence comprend 6 règles fondamentales réparties en trois catégories : Stratégie de test (niveau critique), Tests de bout en bout (priorité élevée) et Tests unitaires (priorité moyenne). Parmi les principales compétences, on trouve des conseils sur le choix entre tests de bout en bout et tests unitaires, la manière de structurer les tests de bout en bout dans le répertoire approprié, les bonnes pratiques d’utilisation de sélecteurs accessibles dans les tests Playwright, la manière d’éviter les tests unitaires sur les composants React, et la simplicité des simulations. Les règles s’appuient sur des exemples de code concrets comparant les bonnes et les mauvaises approches, afin de rendre ces directives immédiatement applicables.
Cette compétence est idéale pour les développeurs front-end travaillant sur des applications web qui doivent prendre des décisions en matière de tests, écrire de nouveaux tests ou réviser du code de test. Elle est particulièrement utile pour les équipes utilisant Playwright pour les tests E2E et React pour les composants d’interface utilisateur. Utilisez cette compétence lorsque vous devez choisir le type de test à écrire, mettre en œuvre une nouvelle couverture de test, refactoriser des tests existants ou effectuer des revues de code sur des fichiers de test. Ces directives aident les équipes à éviter les anti-modèles courants en matière de tests et à créer des suites de tests qui inspirent une réelle confiance dans le comportement de l’application.
FAQ
Quand faut-il privilégier les tests unitaires plutôt que les tests de bout en bout (E2E) ?
Privilégiez les tests E2E dans la plupart des cas. N’écrivez des tests unitaires que pour des fonctions pures qui ne comportent aucune dépendance et exécutent une logique isolée, comme le formatage de données ou des calculs. Si vous testez quoi que ce soit impliquant des composants React, des appels d’API ou des interactions utilisateur, rédigez plutôt un test E2E.
Quel framework de test cette compétence suppose-t-elle ?
La compétence utilise Playwright pour les exemples de tests E2E et fait référence à MSW (Mock Service Worker) pour la simulation d’API. Les exemples de composants React suggèrent une pile front-end JavaScript/TypeScript, mais les principes fondamentaux s’appliquent à n’importe quel framework front-end.
À partir de combien de simulations peut-on considérer qu’un test comporte trop de simulations ?
Si vous avez besoin de 3 mocks ou plus dans un seul test, c’est le signe qu’il vaut mieux écrire un test E2E à la place. Les mocks simples (comme un seul handler MSW pour un point de terminaison API) sont acceptables, mais les configurations de mocks complexes indiquent que vous devriez tester le véritable système intégré.
Où les tests E2E doivent-ils être placés dans le projet ?
Les tests E2E doivent être placés dans le répertoire e2e/tests/ à la racine du projet, et non dans le répertoire frontend/. Cela permet de les distinguer des tests unitaires et d’indiquer clairement qu’ils testent l’ensemble du système.
Quelle stratégie de sélection dois-je utiliser dans les tests Playwright ?
Respectez l’ordre de priorité suivant : les sélecteurs basés sur les rôles (getByRole) sont préférables, puis ceux basés sur les étiquettes (getByLabel), ensuite le contenu textuel, et enfin les identifiants de test (getByTestId) uniquement lorsqu’aucun sélecteur accessible n’existe. Évitez les sélecteurs CSS, car ils sont fragiles et ne reflètent pas la manière dont les utilisateurs interagissent avec l’application.
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
Tous les fichiers
7 fichiersInstaller frontend-testing-best-practices
Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.
Télécharger le ZIPClonez le dépôt et copiez les fichiers de compétence dans votre projet.
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
Copier
