Introduction aux tests unitaires

Installer Vitest

• Vitest est un outil de test moderne, rapide, qui comprend directement import/export. Sa syntaxe est la même que celle de Jest, très répandu.
• Dans un projet qui a déjà un package.json avec "type": "module" (voir la leçon précédente) :

npm install --save-dev vitest
npm pkg set scripts.test="vitest"

• Organisation conseillée : le code dans src/, les tests dans tests/, avec un fichier de test par module, nommé nom.test.js.

mon-projet/
├── package.json
├── src/
│   └── notes.js
└── tests/
    └── notes.test.js

Le code à tester

• Le module src/notes.js exporte trois fonctions pures :

export const NOTE_MIN = 0;
export const NOTE_MAX = 20;
export const SEUIL_ADMISSION = 10;

export function estNoteValide(note) {
  return typeof note === "number" && note >= NOTE_MIN && note <= NOTE_MAX;
}

export function calculerMoyenne(notes) {
  if (!Array.isArray(notes) || notes.length === 0) {
    throw new Error("La liste de notes est vide");
  }
  if (!notes.every(estNoteValide)) {
    throw new RangeError("Une note est hors de l'intervalle 0-20");
  }
  const total = notes.reduce((somme, note) => somme + note, 0);
  return Math.round((total / notes.length) * 100) / 100;
}

export function obtenirDecision(moyenne) {
  return moyenne >= SEUIL_ADMISSION ? "Admis" : "Ajourné";
}

6. Écrire les tests

import { describe, it, expect } from "vitest";
import { estNoteValide, calculerMoyenne, obtenirDecision } from "../src/notes.js";

describe("calculerMoyenne", () => {
  it("calcule la moyenne de plusieurs notes", () => {
    // Arrange (préparer)
    const notes = [12, 15, 9];
    // Act (agir)
    const resultat = calculerMoyenne(notes);
    // Assert (vérifier)
    expect(resultat).toBe(12);
  });

  it("arrondit à deux décimales", () => {
    expect(calculerMoyenne([14, 15, 9])).toBe(12.67);
  });

  it("refuse une liste vide", () => {
    expect(() => calculerMoyenne([])).toThrow("vide");
  });

  it("refuse une note supérieure à 20", () => {
    expect(() => calculerMoyenne([12, 25])).toThrow(RangeError);
  });
});

describe("estNoteValide", () => {
  it.each([
    [0, true],
    [20, true],
    [-1, false],
    [21, false],
    ["15", false],
  ])("estNoteValide(%s) renvoie %s", (note, attendu) => {
    expect(estNoteValide(note)).toBe(attendu);
  });
});

describe("obtenirDecision", () => {
  it("admet un stagiaire qui a exactement 10", () => {
    expect(obtenirDecision(10)).toBe("Admis");
  });

  it("ajourne un stagiaire qui a 9.99", () => {
    expect(obtenirDecision(9.99)).toBe("Ajourné");
  });
});

• describe("...", () => { ... }) regroupe les tests d'une même fonction.
• it("...", () => { ... }) (ou test) décrit un comportement attendu, rédigé comme une phrase.
• expect(valeur) suivi d'un comparateur vérifie le résultat.
• it.each([...]) exécute le même test avec plusieurs jeux de données.
• Le schéma AAA: Arrange (préparer les données), Act (appeler la fonction), Assert (vérifier le résultat).

Les comparateurs les plus utiles

Lancer les tests et lire le résultat

• npm test lance Vitest en mode surveillance: les tests sont relancés à chaque enregistrement (touche q pour quitter). npx vitest run les exécute une seule fois.
• Si tous les tests passent :

 ✓ tests/notes.test.js (11 tests) 4ms

 Test Files  1 passed (1)
      Tests  11 passed (11)

• Imaginons qu'un collègue remplace par erreur >= par > dans obtenirDecision. Le test le détecte immédiatement :

 FAIL  tests/notes.test.js > obtenirDecision > admet un stagiaire qui a exactement 10
AssertionError: expected 'Ajourné' to be 'Admis' // Object.is equality
Expected: "Admis"
Received: "Ajourné"
 ❯ tests/notes.test.js:41:33

 Test Files  1 failed (1)
      Tests  1 failed | 10 passed (11)

• Le message indique le test qui échoue, la valeur attendue (Expected), la valeur obtenue (Received) et la ligne du test.
• Couverture de code: npm install --save-dev @vitest/coverage-v8 puis npx vitest run --coverage affiche le pourcentage du code exécuté par les tests.

Quels cas tester ?

• Le cas normal: une moyenne de trois notes.
• Les valeurs limites: 0, 20, 10 tout juste, 9.99… C'est là que se cachent la plupart des bugs (> au lieu de >=).
• Les cas d'erreur: liste vide, note négative, texte au lieu d'un nombre.
• Un bug corrigé: on ajoute un test qui le reproduit, pour qu'il ne revienne jamais.

Découvrir le TDD

• Le TDD (Test-Driven Development, développement piloté par les tests) inverse l'ordre habituel, en trois étapes répétées :

1. Rouge: écrire un test pour une fonctionnalité qui n'existe pas encore ; il échoue.
2. Vert: écrire le code le plus simple qui fait passer le test.
3. Refactoriser: améliorer le code en gardant tous les tests au vert.

• Cette démarche oblige à réfléchir au comportement attendu avant de coder.

Activités

À retenir

• Un test unitaire vérifie automatiquement une fonction isolée ; on le relance après chaque modification.
• Structure : describe → it → expect(...).toBe(...), selon le schéma Préparer – Agir – Vérifier.
• On teste le cas normal, les valeurs limites et les cas d'erreur.
• Les fonctions pures, séparées du DOM, sont les plus faciles à tester.

Sources : MDN Web Docs (developer.mozilla.org), OWASP (owasp.org), documentations d'ESLint, Prettier et Vitest.