Tester le web : Vitest & Testing Library

Bonne nouvelle : tu sais déjà tester. Jest, Testing Library, msw, des flows Maestro — ce module n'est pas un apprentissage mais une traduction : l'outillage web et l'outillage mobile sont les mêmes idées sous d'autres noms. Ce qu'on travaille ici, c'est le jugement : quoi tester, à quel niveau, et comment distinguer un bon test d'un test qui coûtera cher. Beaucoup de tests techniques de stage livrent un squelette de tests à compléter, et ta façon de les lire compte autant que ton code.

Pourquoi on teste, sans dogme

Deux discours extrêmes circulent, faux tous les deux. « Tout doit être testé, 100 % de couverture » produit des suites gigantesques et fragiles que personne n'ose toucher. « Les tests sont une perte de temps, on verra quand le produit sera stabilisé » produit des applications où chaque correction en casse deux autres. La vérité utile tient dans une question de coût : un test vaut la peine quand il coûte moins cher à écrire et à maintenir que le bug qu'il empêche.

Encore faut-il savoir ce qu'un test t'achète — pas seulement « attraper des bugs », mais trois choses, dont la première est la plus sous-estimée.

1. Un contrat exécutable. « Le bouton est désactivé pendant l'envoi » ne décrit pas ton code : ça décrit une promesse faite à l'utilisateur. Le jour où quelqu'un — toi dans six mois, un collègue, un agent qui refactorise — casse cette promesse, la machine le lui dit immédiatement, avant la production.

2. Une documentation qui ne ment pas. Un README vieillit en silence, un commentaire devient faux sans prévenir. Un test, lui, échoue dès qu'il décrit un comportement que le code n'a plus : c'est la seule documentation du métier vérifiée en continu. Sur un projet inconnu, lire les noms des tests renseigne souvent mieux que lire le code — on y revient dans la dernière section.

3. La permission de changer d'avis. Le vrai bénéfice quotidien. Sans tests, chaque refonte est un pari : tu n'oses pas toucher au code qui marche, donc le code pourrit. Avec des tests de comportement, tu réécris un composant de fond en comble et tu sais en dix secondes si le produit se comporte pareil. Les tests ne figent pas le code — ils le libèrent.

La pyramide, et pourquoi le frontend la déforme

Trois étages. À la base, les tests unitaires : une fonction, isolée, sans DOM ni réseau — rapides, précis, bon marché. Au milieu, l'intégration : plusieurs pièces qui collaborent, un composant avec son état, ses enfants, son appel réseau simulé. Au sommet, le bout en bout (end-to-end) : vraie application, vrai navigateur, vrai serveur — lent, coûteux, mais seul à prouver que l'ensemble fonctionne. La forme pyramidale (beaucoup d'unitaire, très peu de bout en bout) vient du backend, où la valeur tient dans des fonctions de calcul qui s'isolent bien.

Le frontend a déplacé le centre de gravité vers le milieu, parce qu'en interface les bugs ne vivent presque jamais dans une fonction isolée : ils vivent dans le câblage. Le champ n'est pas relié à son étiquette ; le bouton n'est pas désactivé au bon moment ; l'erreur du serveur est reçue mais jamais affichée. Un test unitaire sur chacune de ces pièces passerait au vert, et l'écran serait quand même cassé. D'où l'image du trophée : une base d'unitaires pour la logique pure, un gros ventre d'intégration pour les écrans, une poignée de bout en bout pour les parcours qui rapportent de l'argent.

L'anatomie d'un fichier de test

Avant les outils, le vocabulaire. Tout fichier de test JavaScript moderne — Jest, Vitest, Node lui-même — est construit avec les trois mêmes briques.

• describe(nom, fn) — un regroupement, purement organisationnel : un titre au-dessus d'un paquet de tests dans le rapport, en général le nom de ce qu'on teste.
• it(nom, fn) — un test. Un cas, une phrase, un verdict. test(nom, fn) est un synonyme exact ; le choix est affaire de goût d'équipe. Le nom it vient d'une tradition de lecture à voix haute : le nom du test doit former une phrase complète décrivant un comportement.
• expect(valeur).unMatcher(attendu) — une assertion. expect emballe la valeur observée, et le matcher (toBe, toEqual, toHaveBeenCalled…) décrit la comparaison à faire.

Arrange, Act, Assert

Un bon test a trois temps, toujours dans le même ordre. Arrange — le décor : données d'entrée, rendu du composant, doublures (les faux objets qui remplacent le réseau ou l'horloge, détaillés plus bas). Act — une chose : on appelle, on clique, on tape ; trois actions = probablement trois tests. Assert — on vérifie que l'observé correspond à la promesse. Ce n'est pas une règle de syntaxe mais de lisibilité : quand les trois temps sont mélangés, le test devient un script dont l'échec ne t'apprend plus rien — « quelque chose » a cassé, quelque part dans douze étapes.

import { describe, it, expect } from 'vitest';
import { validateAppointment } from './rendez-vous';

describe('validateAppointment', () => {
  it('refuse un email sans arobase', () => {
    // ARRANGE — un jeu de valeurs valide, sauf le email qu'on veut éprouver.
    const values = {
      nom: 'Patrick',
      email: 'patrick.exemple.ca',
      date: '2030-01-12',
      service: 'physio',
    };

    // ACT — une seule action : on appelle la fonction.
    const errors = validateAppointment(values);

    // ASSERT — on vérifie la promesse, et RIEN d'autre.
    expect(errors.email).toBeDefined();
    expect(errors.nom).toBeUndefined(); // les autres fields restent valides
  });
});

Le validateur pur du module Formulaires 2 — validation & erreurs, testé directement. Aucun composant, aucun DOM, aucun réseau : ce test tourne en une fraction de milliseconde.

Le nom du test est la moitié du travail

Le nom d'un test n'est pas une étiquette administrative : c'est ce que tu liras le jour où il échouera, souvent dans un rapport d'intégration continue — le serveur qui rejoue toute la suite à chaque envoi de code —, à froid, sans le code sous les yeux. Compare :

La règle mécanique : un bon nom contient un verbe au présent (ce que le système fait) et une condition (quand). « Affiche X quand Y ». « Refuse X si Y ». Il ne mentionne ni le nom de la fonction interne, ni la technique employée. Un test nommé it('appelle setState avec le bon objet') te dit qu'il teste l'implémentation, avant même que tu lises son corps.

it('valide le email', async () => {
  render(<AppointmentForm />);
  await userEvent.type(screen.getByLabelText('Courriel'), 'patrick.ca');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
});

Vitest en pratique : juste assez pour reconnaître un projet configuré

Vitest est un lanceur de tests (test runner) : le programme qui trouve tes fichiers de test, les exécute et te dit ce qui passe — le rôle exact de Jest dans Halterofit. Il est bâti sur Vite, donc il partage la configuration du projet : TypeScript, JSX, alias d'import (@/composants/…), fichiers CSS, tout est compris d'emblée. Et il ne recompile que ce qui a changé, d'où sa rapidité.

Le point important : l'API est volontairement compatible avec Jest. describe, it, expect, beforeEach, les matchers, le mode veille : identiques. Seule différence visible, l'objet utilitaire s'appelle vi au lieu de jest (vi.fn(), vi.mock(), vi.spyOn()). Ton acquis mobile se transpose par un chercher-remplacer mental — et si ton stage utilise Jest, tu ne changes rien.

jsdom : un navigateur en carton, et c'est très bien

Node.js, tout seul, n'a pas de DOM : pas de document, pas de window, pas d'<input>. jsdom est une réimplémentation du DOM en pur JavaScript, en mémoire dans le processus Node : ton test rend un composant, jsdom fabrique un arbre d'éléments consultable, Testing Library l'interroge. Rien n'est affiché à l'écran ; c'est une simulation, avec des limites qui définissent ce que ce niveau de test peut prouver.

• Aucune mise en page réelle. jsdom ne calcule ni positions ni tailles : tout élément mesure zéro. Donc pas de test de visibilité à l'écran, de responsive ou de chevauchement — ce sont des tests de navigateur réel.
• Le CSS n'est pas vraiment appliqué. jsdom lit les styles en ligne mais ne résout ni les feuilles de style ni les classes. Vérifier une couleur ou un display: none venu d'une classe est une illusion.
• Des API manquantes. IntersectionObserver, matchMedia, scrollTo, le canvas ne sont pas implémentés — d'où les doublures qu'on ajoute au fichier de mise en place.

Même logique que sur Halterofit, où LokiJS remplace SQLite en test et où le protocole de synchronisation échappe structurellement à Jest. Une simulation te fait gagner en vitesse ce qu'elle te coûte en fidélité ; le métier consiste à savoir laquelle des deux te manque.

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],          // sait compiler le JSX de tes composants
  test: {
    environment: 'jsdom',      // ← LE réglage clé : un faux DOM pour chaque test
    globals: true,             // describe / it / expect sans les importer
    setupFiles: ['./vitest.setup.ts'],  // fichier joué AVANT chaque fichier de test
  },
});

Quatre lignes qui comptent. Si tu vois environment: 'jsdom', tu sais que le projet teste des composants ; si tu vois 'node', il ne teste que de la logique.

// Ajoute les matchers orientés DOM : toBeInTheDocument, toBeDisabled,
// toHaveTextContent, toHaveValue… Sans cet import, ils n'existent pas.
import '@testing-library/jest-dom/vitest';

import { cleanup } from '@testing-library/react';
import { afterEach } from 'vitest';

// Démonte les composants rendus après chaque test : sinon le DOM s'accumule
// et une requête « getBy » trouve DEUX boutons — l'ancien et le nouveau.
afterEach(() => {
  cleanup();
});

Le fichier de mise en place, c'est « ce qui est vrai pour tous les tests ». C'est aussi là que se démarre le serveur msw, qu'on verra plus bas.

Tu n'as pas à savoir écrire ces fichiers de mémoire, seulement à les reconnaître : dans un dépôt livré pour un test technique, ils te disent en dix secondes quel niveau de test on attend de toi. Et si tu vois @testing-library/jest-dom avec Vitest, ne t'étonne pas : la bibliothèque de matchers a gardé son nom historique.

La philosophie de Testing Library : tester comme l'utilisateur

On arrive au cœur du module. Testing Library n'est pas un lanceur de tests, c'est une bibliothèque de requêtes : elle sert à retrouver des éléments dans le DOM rendu. Sa doctrine tient en une phrase :

Ce n'est pas une préférence esthétique, c'est une stratégie de résistance au changement. Les classes CSS bougent à chaque retouche de design, la structure des <div> dès qu'on ajoute un conteneur, le nom d'un état interne au premier refactor. En revanche, un bouton qui dit Réserver et un champ étiqueté Courriel ne bougent presque jamais — parce que c'est ça, le produit.

L'ordre de priorité des requêtes

Testing Library classe explicitement ses requêtes du meilleur au pire. Ce classement est publié dans la documentation officielle, et le connaître est un signal de sérieux en entrevue.

Le rôle est la notion centrale : ce que l'élément est pour une technologie d'assistance — <button> → button, <a href> → link, <input type="text"> → textbox, <select> → combobox, <h1> → heading. Le second argument, { name: … }, n'est pas l'attribut HTML name : c'est le nom accessible, le texte qu'un lecteur d'écran annoncerait.

// Quelques requêtes typiques sur l'écran de réservation.
screen.getByRole('heading', { name: /prendre rendez-vous/i, level: 1 });
screen.getByRole('textbox', { name: 'Nom complet' });   // l'input relié à son label
screen.getByRole('combobox', { name: 'Service' });      // le <select>
screen.getByRole('button', { name: /réserver/i });      // regex = insensible à la casse
screen.getByRole('alert');                              // le bloc d'erreur, role="alert"

Une expression régulière comme /réserver/i évite de casser si le libellé devient « Réserver mon rendez-vous ». Une chaîne exacte, elle, exige une correspondance complète.

Pourquoi c'est un argument d'entrevue très fort

Le point que peu de juniors savent formuler, et qui fait mouche : un test qui passe par le rôle teste aussi l'accessibilité. Raisonne à l'envers — pour que getByRole('textbox', { name: 'Courriel' }) trouve quelque chose, il faut que le champ ait un nom accessible, donc une étiquette (<label htmlFor>, aria-label, aria-labelledby). Si le développeur a écrit un <div> cliquable au lieu d'un <button>, ou un texte flottant au lieu d'une étiquette, la requête échoue — et elle a raison, cette page est réellement inutilisable au lecteur d'écran.

Ta suite devient donc un audit d'accessibilité continu et gratuit : aucun outil ajouté, juste la bonne requête. À l'inverse, getByTestId('email-input') fonctionne parfaitement sur une page catastrophique — data-testid existe pour les robots, pas pour les humains.

// Le formulaire tel qu'il existe : label + input reliés par for / id.
//   <label for="email">Courriel</label>
//   <input id="email" name="email" type="email" />

// Donc le test le retrouve exactement comme l'utilisateur le lit :
const email = screen.getByLabelText('Courriel');
const service  = screen.getByLabelText('Service');   // le <select>
const notes    = screen.getByLabelText(/précisions/i);

it('affiche une erreur de email', () => {
  const { container } = render(<AppointmentForm />);

  const bouton = container.querySelector('.btn.btn--primary');
  fireEvent.click(bouton);

  const erreur = container.querySelector('.form__error--email');
  expect(erreur).not.toBeNull();
  expect(erreur.textContent).toContain('Courriel invalide');
});

it('affiche une erreur quand le email est invalide', async () => {
  render(<AppointmentForm />);

  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));

  expect(await screen.findByText(/email/i)).toBeInTheDocument();
});

// le composant
<div className="field">
  <span className="field__label">Courriel</span>
  <input type="email" placeholder="nom@exemple.ca" />
</div>

// le test
screen.getByLabelText('Courriel');

getBy, queryBy, findBy : trois familles, trois usages

Ces trois préfixes se combinent avec tous les suffixes de la table précédente (getByRole, queryByRole, findByRole…). Ils cherchent la même chose ; ce qui change, c'est leur comportement quand l'élément n'est pas là — et c'est la source d'échec numéro un des débutants en Testing Library.

Une quatrième famille existe au pluriel — getAllBy…, queryAllBy…, findAllBy… — qui renvoie un tableau (les lignes d'une liste, les créneaux disponibles). Au passage, les versions au singulier échouent aussi quand elles trouvent plusieurs correspondances : « Found multiple elements » signale souvent un vrai problème d'interface — deux boutons qui disent la même chose sans se distinguer, ce qui embrouille aussi l'utilisateur au lecteur d'écran.

Le piège classique : getBy sur ce qui n'existe pas encore

Tu cliques sur « Réserver » ; le composant lance un fetch, attend la réponse, puis affiche « Rendez-vous confirmé ». Or un fetch, même simulé, même instantané, est asynchrone : sa résolution est mise en file d'attente et ne se produit qu'après la fin du code en cours. À la ligne suivant le clic, React n'a donc rien reçu, rien mis à jour, rien re-rendu.

// ❌ Échoue : « Unable to find an element with the text… »
await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
expect(screen.getByText(/rendez-vous confirmé/i)).toBeInTheDocument();

// ✅ findBy ATTEND que l'élément apparaisse (il réessaie jusqu'à ~1 seconde).
await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
expect(await screen.findByText(/rendez-vous confirmé/i)).toBeInTheDocument();

// ✅ queryBy pour prouver une ABSENCE : il rend null au lieu de planter.
expect(screen.queryByRole('alert')).not.toBeInTheDocument();

Retiens l'équation : findBy ≈ waitFor + getBy. Il réessaie la requête à intervalles courts jusqu'à la trouver ou jusqu'au délai maximum.

Pourquoi ne pas toujours utiliser findBy ? Parce qu'un getBy qui échoue échoue tout de suite, tandis qu'un findBy coûte une seconde par occurrence. Surtout, getBy exprime une intention plus forte : « cet élément doit déjà être là ».

it('confirme la réservation', async () => {
  render(<PageRendezVous />);

  await userEvent.type(screen.getByLabelText('Courriel'), 'a@b.ca');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));

  expect(screen.getByText(/rendez-vous confirmé/i)).toBeInTheDocument();
});

it('n’affiche pas d’erreur quand le email est valide', () => {
  render(<AppointmentForm />);
  expect(screen.queryByText('Erreur')).not.toBeInTheDocument();
});

Simuler l'utilisateur : userEvent plutôt que fireEvent

Deux façons de déclencher une interaction, et le choix suit la même logique que celui des requêtes. fireEvent.click(element) émet un événement DOM brut, isolé — l'équivalent d'appeler directement le gestionnaire. userEvent.click(element) simule ce que fait un vrai humain avec une vraie souris : vérifier que l'élément n'est ni désactivé ni caché, déplacer le pointeur, appuyer, donner le focus, relâcher, puis seulement émettre le click. De même, userEvent.type() envoie pour chaque caractère une séquence keydown / keypress / input / keyup, en respectant la position du curseur.

La différence n'est pas cosmétique. Un menu qui s'ouvre au survol, un champ qui valide à la perte de focus, un composant qui écoute keydown plutôt que change : fireEvent donne un résultat qui ne correspond à rien de réel. Pire, sur un bouton désactivé, fireEvent.click déclenche joyeusement le gestionnaire — ton test valide un chemin impossible. userEvent refuse, comme le navigateur.

Conséquence pratique : toutes les méthodes de userEvent sont asynchrones, parce qu'elles enchaînent plusieurs événements et laissent React traiter les rendus intermédiaires. Il faut donc les await — l'oubli est l'autre grande source de tests instables : la suite s'exécute pendant que la frappe est encore en cours.

import userEvent from '@testing-library/user-event';

// Forme recommandée : on crée une « session » utilisateur en début de test.
const user = userEvent.setup();

await user.type(screen.getByLabelText('Nom complet'), 'Patrick');
await user.selectOptions(screen.getByLabelText('Service'), 'physio');
await user.clear(screen.getByLabelText('Courriel'));      // vide le champ
await user.tab();                                          // passe au champ suivant
await user.click(screen.getByRole('button', { name: /réserver/i }));

userEvent.setup() installe une session cohérente (position du pointeur, presse-papiers, état des touches modificatrices). Appeler userEvent.click(…) directement fonctionne aussi et fait un setup() implicite ; les deux formes se croisent dans la nature.

user.tab() est sous-utilisé : il simule Tab et déplace le focus au prochain élément focalisable. C'est ta façon de tester la navigation au clavier — qu'un modal piège le focus, qu'un champ valide en le quittant, que l'ordre de tabulation est cohérent. Un test de parcours clavier dans un exercice technique est un signal de maturité rare chez un junior.

it('envoie les values saisies quand le formulaire est soumis', async () => {
  render(<PageRendezVous />);
  await userEvent.selectOptions(screen.getByLabelText('Service'), 'Échographie');
  await userEvent.type(screen.getByLabelText('Courriel'), 'a@b.ca');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
  expect(await screen.findByText(/rendez-vous confirmé/i)).toBeInTheDocument();
});

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { PageRendezVous } from './PageRendezVous';

describe('PageRendezVous', () => {
  it('confirme la réservation quand le formulaire est valide', async () => {
    // ARRANGE
    const user = userEvent.setup();
    render(<PageRendezVous />);

    // ACT — le parcours complet, dans l'ordre où un humain le ferait.
    await user.type(screen.getByLabelText('Nom complet'), 'Patrick Patenaude');
    await user.type(screen.getByLabelText('Courriel'), 'patrick@exemple.ca');
    await user.selectOptions(screen.getByLabelText('Service'), 'echo');
    await user.click(screen.getByRole('button', { name: /réserver/i }));

    // ASSERT — ce que l'utilisateur voit, et rien d'autre.
    expect(await screen.findByText(/rendez-vous confirmé/i)).toBeInTheDocument();
    expect(screen.queryByRole('alert')).not.toBeInTheDocument();
  });

  it('désactive le bouton pendant l’envoi', async () => {
    render(<PageRendezVous />);
    // ... remplissage ...
    await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
    expect(screen.getByRole('button', { name: /en cours/i })).toBeDisabled();
  });
});

Les doublures : espions, mocks et faux réseau

Un test doit être déterministe : même entrée, même résultat. Or une interface parle à des choses imprévisibles — un serveur, l'horloge, le routeur. On les remplace par des doublures (test doubles). Quatre familles utiles, de la plus légère à la plus lourde.

1. vi.fn() — l'espion

vi.fn() crée une fonction vide qui enregistre tous ses appels : combien de fois, avec quels arguments, dans quel ordre. L'outil parfait quand ton composant reçoit une fonction en prop et que tu veux vérifier qu'il l'appelle, sans exécuter la vraie logique derrière.

it('transmet les values saisies à onSubmit', async () => {
  const onSubmit = vi.fn();                     // un espion : ne fait rien, note tout
  render(<AppointmentForm onSubmit={onSubmit} />);

  await userEvent.type(screen.getByLabelText('Nom complet'), 'Patrick');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));

  expect(onSubmit).toHaveBeenCalledTimes(1);    // exactement une fois : pas de double envoi
  expect(onSubmit).toHaveBeenCalledWith(
    expect.objectContaining({ nom: 'Patrick' }), // on ne vérifie QUE ce qui compte
  );
});

expect.objectContaining évite d'énumérer tout l'objet : le test ne casse pas si on ajoute un champ « notes » plus tard. Un test trop précis est un test qui casse pour rien.

Le matcher toHaveBeenCalledTimes(1) est souvent plus utile que toHaveBeenCalled() : il attrape la classe de bugs « appelé deux fois » — double-soumission, effet qui se déclenche à chaque rendu, gestionnaire attaché en double.

2. vi.mock() — remplacer un module entier

Quand la dépendance n'est pas passée en prop mais importée par le composant, il faut intercepter l'import lui-même. C'est le rôle de vi.mock() : « quand quelqu'un importe ce module, donne-lui ça à la place ». Le cas le plus fréquent en Next.js est le routeur.

// Remonté automatiquement en haut du fichier : le mock existe avant les imports.
const push = vi.fn();

vi.mock('next/navigation', () => ({
  useRouter: () => ({ push, replace: vi.fn(), refresh: vi.fn() }),
  useSearchParams: () => new URLSearchParams(),
}));

it('redirige vers la confirmation après une réservation', async () => {
  render(<PageRendezVous />);
  // ... parcours ...
  expect(push).toHaveBeenCalledWith('/rendez-vous/confirmation');
});

Sans ce mock, useRouter() plante en test : il n'y a pas de routeur Next.js en dehors d'une vraie application. C'est de la plomberie obligatoire, pas un test en soi.

Regarde quand même ce que l'assertion vérifie : un push vers /rendez-vous/confirmation après une réservation réussie. C'est la seconde moitié de Le lien qui reste un lien, du module Routing : segments, layouts, navigation — Link pour ce que l'utilisateur clique, useRouter() pour les navigations que le code déclenche. D'où une lecture utile en revue : un test qui simule useRouter signale une navigation impérative, et vaut la peine qu'on vérifie qu'elle en est vraiment une — si l'utilisateur cliquait simplement sur « voir la confirmation », il fallait un lien.

Avertissement de dosage : vi.mock() est puissant, donc dangereux. Chaque module simulé est un morceau de réel que ton test cesse de vérifier. Si tu simules le composant enfant, la validation et le client HTTP, ton test vérifie essentiellement tes propres mocks. Règle de pouce : on simule ce qui est hors du logiciel (réseau, horloge, framework), pas ce qui est ton logiciel.

3. vi.spyOn() — surveiller sans remplacer

vi.spyOn(objet, 'méthode') pose un espion sur une méthode existante — par défaut sans changer son comportement, avec mockImplementation pour la neutraliser. L'usage le plus courant dans les tests techniques est console.log : beaucoup d'énoncés disent « à la soumission, affiche les valeurs dans la console ». Si c'est la consigne, c'est la promesse — donc c'est ce qu'on teste.

it('journalise les values soumises', async () => {
  // mockImplementation(() => {}) : on intercepte ET on rend l'appel silencieux,
  // sinon la sortie du test est polluée par les logs de l'application.
  const espion = vi.spyOn(console, 'log').mockImplementation(() => {});

  render(<AppointmentForm />);
  await userEvent.type(screen.getByLabelText('Nom complet'), 'Patrick');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));

  expect(espion).toHaveBeenCalledWith(
    expect.objectContaining({ nom: 'Patrick' }),
  );

  espion.mockRestore(); // ← indispensable : on rend sa vraie méthode à console
});

Le mockRestore() n'est pas facultatif. Un espion laissé en place fuit dans les tests suivants du même fichier, et tu passeras un long moment à comprendre pourquoi un test isolé passe mais échoue dans la suite complète.

Le même espion sert aussi en négatif, et c'est un usage élégant : expect(vi.spyOn(console, 'error')).not.toHaveBeenCalled() transforme les avertissements React — « a component is changing a controlled input to be uncontrolled », une clé manquante dans une liste — en échecs de test. Tu ne peux plus les ignorer.

4. msw — intercepter le réseau, pas ton code

Tu connais déjà l'outil. msw (Mock Service Worker) n'écrase pas ta fonction fetch : il intercepte les requêtes au niveau du réseau et répond à leur place. La différence est capitale — ton code appelle vraiment fetch, avec sa vraie URL, ses vrais en-têtes, son vrai corps JSON, et reçoit une vraie Response. Aucune ligne de production n'est modifiée pour le test.

import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

const server = setupServer(
  // Le comportement NOMINAL : la clinique accepte la réservation.
  http.post('/api/appointments', () =>
    HttpResponse.json({ id: 'rdv_42' }, { status: 201 }),
  ),
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers()); // on efface les surcharges d'un test à l'autre
afterAll(() => server.close());

it('affiche un message d’échec quand l’API répond 500', async () => {
  // Surcharge LOCALE : juste pour ce test, le serveur tombe en panne.
  server.use(
    http.post('/api/appointments', () => new HttpResponse(null, { status: 500 })),
  );

  render(<PageRendezVous />);
  // ... parcours de réservation ...
  expect(await screen.findByRole('alert')).toHaveTextContent(/impossible de réserver/i);
});

Le server.use() local est la technique la plus rentable de tout msw : le chemin heureux est défini une fois pour toutes, et chaque test qui veut un échec le déclare sur une ligne.

Ce dernier test vaut de l'or, parce que le chemin d'erreur est celui que personne ne teste à la main. C'est exactement là que se cache l'oubli du res.ok vu dans le module Formulaires 1 — l'application affiche fièrement « Rendez-vous confirmé » alors que le serveur a renvoyé 500. Un test msw de trois lignes attrape ce bug pour toujours.

Ce qui vaut la peine d'être testé

Savoir écrire un test est la partie facile ; savoir lesquels écrire est le vrai métier — et c'est là qu'un junior se distingue, parce que la réponse naïve (« tout ») produit une suite lente, fragile, qui finit désactivée.

La règle du risque

On n'alloue pas l'effort par type de fonction, mais par coût du bug : si ce morceau de code casse silencieusement, qu'est-ce qui se passe ? La hiérarchie qui en découle est assez universelle :

Tu reconnais cette échelle : c'est celle de la stratégie de test d'Halterofit, au vocabulaire près. Elle est universelle parce qu'elle ne dit rien de la technologie — seulement « le test doit être proportionné à ce que le bug coûte ».

Ne teste pas le framework

Corollaire souvent violé. React et Next.js sont testés par leurs auteurs ; ton travail n'est pas de revérifier que useState met à jour une valeur ou que <input value> affiche ce qu'on lui donne. Les tests suivants ont l'air sérieux et ne valent rien :

• « le composant se rend sans planter » — vrai de presque tout composant ;
• « taper dans le champ met l'état à jour » — c'est le contrat de React, pas le tien ;
• « le composant affiche le texte de sa prop » — c'est du JSX, pas une règle métier ;
• « la liste rend N éléments pour N données » — sauf si le filtrage ou le tri est justement la logique à prouver.

Le test de fumée « ça se rend » a une seule justification : un garde grossier sur un écran complexe. Assumé comme tel, c'est honnête ; vendu comme de la couverture, c'est de l'illusion — et la couverture de code est une mesure trompeuse : elle mesure les lignes exécutées, pas les comportements vérifiés. Une suite sans une seule assertion peut afficher 90 %.

Le meilleur rapport valeur / effort : extraire, puis tester la fonction pure

Le geste le plus rentable du module ne parle pas de tests, il parle d'architecture. Une logique enfouie dans un composant est chère à tester (il faut rendre, cliquer, attendre, interroger le DOM pour une règle de trois lignes) ; extraite dans une fonction pure, elle se teste en une milliseconde avec vingt cas limites. C'est la raison d'être du validateur pur du module Formulaires 2 : validateAppointment(values) ne connaît ni React, ni le DOM, ni le réseau — on lui donne un objet, elle rend un dictionnaire d'erreurs.

// Un seul test, table de cas : chaque ligne est une règle du cahier des charges.
const CAS = [
  { nom: 'nom vide',        values: { ...VALIDE, nom: '   ' },              champ: 'nom' },
  { nom: 'email sans @', values: { ...VALIDE, email: 'patrick.ca' },  champ: 'email' },
  { nom: 'date passée',     values: { ...VALIDE, date: '2020-01-01' },      champ: 'date' },
  { nom: 'service absent',  values: { ...VALIDE, service: '' },             champ: 'service' },
] as const;

it.each(CAS)('signale une erreur pour : $nom', ({ values, champ }) => {
  expect(validateAppointment(values)[champ]).toBeDefined();
});

it('ne signale aucune erreur pour un formulaire valide', () => {
  expect(validateAppointment(VALIDE)).toEqual({});
});

it.each génère un test par ligne du tableau, avec un nom lisible dans le rapport. Ajouter une règle métier, c'est ajouter une ligne — et le rapport d'échec te dit laquelle.

Corollaire : une fois la règle couverte à l'unité, ne la re-teste pas à travers l'interface. Un seul test d'intégration suffit à prouver le câblage — que l'erreur du validateur atteint l'écran — sans repasser les quinze cas limites. On appelle ça « ne pas re-tester à travers les couches » : c'est la différence entre une suite qui tourne en huit secondes et une qui tourne en quatre minutes.

// (A) — lib/validation/rendez-vous.test.ts
it('refuse un email sans arobase', () => {
  expect(validateAppointment({ ...VALIDE, email: 'patrick.ca' }).email).toBeDefined();
});

// (B) — app/rendez-vous/PageRendezVous.test.tsx
it('affiche une erreur quand le email est invalide', async () => {
  render(<PageRendezVous />);
  await userEvent.type(screen.getByLabelText('Courriel'), 'patrick.ca');
  await userEvent.click(screen.getByRole('button', { name: /réserver/i }));
  expect(await screen.findByRole('alert')).toHaveTextContent(/email/i);
});

Lire une suite de tests qu'on ne connaît pas

Dernière section, peut-être la plus rentable pour un stage : en équipe comme en test technique, tu passeras bien plus de temps à lire des tests qu'à en écrire. Voici la démarche, en trois passes, dans cet ordre.

Passe 1 — les noms, et seulement les noms. Ne lis que les describe et les it. Tu obtiens en trente secondes la spécification du comportement attendu — la meilleure documentation du module, à jour par construction. Si à la fin de cette passe tu ne sais toujours pas ce que fait le composant, tu viens d'apprendre quelque chose : les tests sont mal nommés, donc probablement écrits après coup pour la couverture, donc peu fiables comme filet.

Passe 2 — le décor. Regarde ce qui est partagé : beforeEach, vi.mock, gestionnaires msw, objets de données réutilisés. Cette passe répond à qu'est-ce qui est faux dans ce test ? Chaque doublure marque une frontière : un fichier qui simule douze modules dit un composant très couplé ; un fichier qui ne simule que le réseau dit une architecture saine.

Passe 3 — les assertions. Seulement maintenant, lis les expect et pose la question du niveau : parlent-ils de ce que l'utilisateur voit (findByRole, toBeDisabled) ou de rouages internes (noms de classes, état interne) ? La réponse te dit, mieux que n'importe quelle métrique, si cette suite va t'aider ou te gêner.

Les it.todo d'un test technique

Format très répandu d'exercice de stage : un dépôt avec un fichier de test déjà écrit… mais vide. Des it.todo('…') — des tests déclarés sans corps, que le lanceur affiche comme « à faire » sans les compter en échec. Ta tâche : les remplir, ou écrire le code qui les fera passer.

describe('PageRendezVous', () => {
  it.todo('affiche une erreur quand le email est invalide');
  it.todo('n’envoie rien tant que le formulaire est invalide');
  it.todo('désactive le bouton pendant l’envoi');
  it.todo('affiche un message d’échec quand l’API répond 500');
  it.todo('vide les fields après une réservation réussie');
});

Ce n'est pas une liste de corvées : c'est la grille de notation, écrite noir sur blanc par l'évaluateur.

Cette liste te dit quatre choses, et savoir les extraire vaut des points avant la première ligne de code :

• Le périmètre exact. Cinq comportements, pas six. Rien sur le design, l'animation ou la persistance. Livrer une bibliothèque de composants magnifique sans faire passer les cinq tests, c'est avoir échoué à l'exercice.
• Le niveau attendu. « désactive le bouton pendant l'envoi » et « affiche un message d'échec quand l'API répond 500 » ne sont pas des tests de fonction pure : ce sont des tests d'intégration avec réseau simulé. L'évaluateur annonce qu'il veut te voir manier msw et findBy.
• Les cas d'erreur comptent autant que le cas heureux. Sur cinq entrées, trois concernent des chemins fâcheux : ce qu'on évalue chez un développeur frontend n'est pas de faire marcher le cas nominal, c'est de penser aux autres.
• Le vocabulaire de l'interface. « vide les champs après une réservation réussie » implique qu'il existe un état de succès et une réinitialisation. Les noms de tests décrivent l'interface attendue, avant même la maquette.

Deux conseils tactiques. Si tu manques de temps, remplis-les dans l'ordre du risque, pas du fichier : le test qui empêche une double réservation vaut plus que celui qui vérifie que les champs se vident. Et ne supprime jamais un it.todo que tu n'as pas fait : laisse-le, mentionne-le dans ton message d'accompagnement. Un candidat lucide sur ce qui manque inspire bien plus confiance qu'un candidat qui efface les traces.