Tester un blog Next.js : Vitest, Testing Library et Playwright

Trois étages

Niveau	Outil	Cible
Unitaire	Vitest	Fonctions de `lib/`, `proxy.ts`
Intégration	Vitest + Testing Library + jsdom	Composants et pages
End-to-end	Playwright	Le vrai site, dans un vrai navigateur

Plus on monte, plus les tests sont réalistes, mais lents et fragiles. La majorité doit donc rester en bas.

Unitaires : la logique pure

Le découpage des diapositives, la validation du frontmatter ou la règle de slug sont des fonctions pures, faciles à tester :

typescript

it("does not split inside a code block", () => {
  const md = "# A\n---\n```\n---\n```\n---\n# B";
  expect(parseSlides(md)).toHaveLength(3);
});

Pensez aux cas hostiles : traversal de chemin, octet nul, CRLF, valeurs falsifiées.

Intégration : composants et pages

Les Server Components asynchrones se testent en les appelant comme des fonctions :

tsx

render(await Footer());

Dans un arbre, mockez les composants asynchrones imbriqués (CodeBlock) : le moteur de rendu de test ne sait pas les monter.

End-to-end : le vrai site

Playwright lance un build de production servi sur un port dédié. C'est important : la vraie CSP et les pages statiques ne sont pas celles du serveur de développement.

Deux astuces qui rendent les tests stables :

attendre l'hydratation d'un composant client avant d'interagir avec lui ;
une fixture automatique qui fait échouer tout test en cas d'erreur console ou de violation de CSP.

La couverture

Des seuils (ici 90 % des instructions, 85 % des branches) évitent que la couverture ne s'érode silencieusement. Ils ne garantissent pas la qualité, mais signalent un trou.

Une commande avant de rendre la main

bash

npm run check   # lint + typecheck + tests

À retenir

Beaucoup de tests unitaires, un peu d'intégration, peu d'e2e ciblés.
Testez le build de production, pas le serveur de dev.
Les tests de sécurité (en-têtes, 404) font partie de la suite.