Écrire un bon test unitaire : AAA, nommage et cas à tester

Un bon test unitaire vérifie un seul comportement d'une unité de code, dans une situation précise, avec un nom qui se lit comme une phrase et une structure en trois temps : préparer (Arrange), agir (Act), vérifier (Assert). Écrire le test est la partie facile ; la vraie compétence consiste à choisir les cas qui ont le plus de chances de révéler un défaut. Ce chapitre, valable dans tous les langages, donne les règles d'écriture et les techniques pour trouver les cas : classes d'équivalence, valeurs limites et tables de décision.

Qu'est-ce qu'une « unité » ?

L'unité est le plus petit morceau de code qui a un comportement observable : une fonction, une méthode, parfois une classe entière quand ses méthodes n'ont de sens qu'ensemble. Un test unitaire l'appelle par son interface publique (ce que le reste du programme utilise) et vérifie ce qu'elle renvoie ou ce qu'elle change, sans regarder comment elle s'y prend.

La structure AAA : préparer, agir, vérifier

Tout test unitaire, dans tous les langages, suit le même schéma en trois temps.

test('refuse un matériel déjà réservé sur une partie de la période', () => {
  // Arrange : le contexte et les données
  const aujourdhui = '2027-03-08';
  const reservations = [{ materiel: 'PC-07', debut: '2027-03-10', fin: '2027-03-14' }];
  const demande = { materiel: 'PC-07', debut: '2027-03-12', fin: '2027-03-18' };

  // Act : un seul appel au code testé
  const resultat = verifierReservation(demande, reservations, aujourdhui);

  // Assert : ce qu'on attend
  expect(resultat.acceptee).toBe(false);
  expect(resultat.motif).toBe('PC-07 est déjà réservé du 10/03/2027 au 14/03/2027.');
});

Trois règles d'usage :

• Une seule action dans la partie Act. Si tu appelles deux fois le code testé avec des données différentes, ce sont deux tests.
• Pas de logique dans un test : ni if, ni boucle, ni calcul de l'attendu. Un test qui contient un if peut lui-même être faux. Pour plusieurs jeux de données, on utilise un test paramétré (test.each, [Theory], #[DataProvider]).
• Les commentaires // Arrange, // Act, // Assert sont utiles quand on débute ; une ligne vide entre les trois parties suffit ensuite.

Le même découpage s'appelle Étant donné / Quand / Alors (Given / When / Then) dans le développement piloté par le comportement (BDD) et dans les critères d'acceptation des user stories. C'est la même idée : un contexte, un événement, un résultat observable.

Nommer un test pour qu'il se lise comme une phrase

Quand un test échoue, son nom est la première chose que tu lis, souvent dans un journal de CI, des semaines après l'avoir écrit. Il doit dire la situation et le résultat attendu, sans qu'on ait besoin d'ouvrir le code.

Les conventions varient selon les langages, l'idée reste la même :

Un test, un comportement

Un test vérifie un comportement, ce qui ne veut pas dire une seule ligne expect. Vérifier qu'une réservation refusée a acceptee à false et le bon motif, c'est vérifier un seul comportement (le refus pour chevauchement) sous deux angles. En revanche, ceci mélange trois comportements :

// À éviter : trois comportements dans un test
test('verifierReservation', () => {
  expect(verifierReservation(demandeLibre, reservations, aujourdhui).acceptee).toBe(true);
  expect(verifierReservation(demandeEnConflit, reservations, aujourdhui).acceptee).toBe(false);
  expect(verifierReservation(demandeTropLongue, reservations, aujourdhui).acceptee).toBe(false);
});

Si la deuxième assertion échoue, la troisième n'est jamais exécutée : tu ne sais pas si la règle de durée marche. Et le nom ne dit pas lequel des trois cas a cassé. Trois tests, trois noms, trois diagnostics.

Les qualités d'un bon test : FIRST

Rendre le code testable : sortir les dépendances cachées

Imagine que verifierReservation lise elle-même la date du jour :

// Difficile à tester : la date du jour est cachée dans la fonction
export function verifierReservation(demande, reservations) {
  const aujourdhui = new Date().toISOString().slice(0, 10);
  // …
}

Le test « accepte une réservation qui commence aujourd'hui » devrait changer de date chaque jour, et le test « refuse une date de début passée » deviendrait faux au fil du temps. La solution est de passer la dépendance en paramètre : la fonction reçoit aujourdhui, l'application lui donne la vraie date, le test lui donne une date fixe.

// Facile à tester : la date du jour est une entrée comme les autres
export function verifierReservation(demande, reservations, aujourdhui) { /* … */ }

C'est la même idée que l'injection de dépendances en programmation objet (injection de dépendances en C#) : une classe reçoit ses dépendances (l'horloge, la base, la messagerie) au lieu de les créer. Les dépendances qu'il faut sortir ainsi sont toujours les mêmes : l'heure, le hasard, la base de données, le réseau, le système de fichiers, les variables d'environnement. Le chapitre 7 montre comment les remplacer par des doublures quand on ne peut pas simplement passer une valeur.

Choisir les cas : les classes d'équivalence

Puisqu'on ne peut pas tout tester, on découpe les entrées possibles en classes d'équivalence : des groupes de valeurs que le programme doit traiter de la même façon. Si le programme marche pour une valeur d'une classe, il marche très probablement pour toutes les autres. On teste alors une valeur par classe, valide ou invalide.

Pour la durée d'un prêt, la règle « un prêt dure au plus 15 jours, premier et dernier jour compris » donne trois classes :

Choisir les cas : les valeurs limites

Les défauts se cachent aux frontières entre les classes : un < à la place d'un <=, un + 1 oublié. L'analyse des valeurs limites consiste à tester, pour chaque frontière, la dernière valeur d'une classe et la première de la suivante.

On applique la même méthode à la date de début : hier (refusé), aujourd'hui (accepté), demain (accepté). Le test « aujourd'hui » est celui que l'on oublie le plus souvent, et c'est lui qui trouve le <= à la place du <.

Choisir les cas : les positions de deux périodes

Le chevauchement de deux périodes est un cas d'école. Une réservation existe du 10 au 14 mars ; la nouvelle demande peut se placer de dix façons différentes par rapport à elle. Chacune est une classe d'équivalence, et plusieurs sont des valeurs limites.

Les cas 2 et 3, puis 9 et 10, sont les frontières : un jour d'écart fait passer le résultat d'« acceptée » à « refusée ». Le cas 9, « commence le jour où l'autre finit », est exactement celui qui manquait à Prêt'Matos dans l'histoire du chapitre 1.

Choisir les cas : la table de décision

Quand le résultat dépend de plusieurs conditions combinées, on dresse une table de décision : une colonne par combinaison utile, une ligne par condition, puis le résultat attendu. Chaque colonne devient un test.

Prenons la route POST /api/reservations/:id/sortie, qui enregistre la sortie d'un matériel :

Le tiret signifie « peu importe » : sans jeton, la réponse est 401 quel que soit le reste. Quatre combinaisons suffisent là où huit seraient possibles. Les tests T1 et T2 sont des tests de sécurité : ils prouvent que la route refuse ce qu'elle doit refuser.

La liste de contrôle des cas oubliés

Une fois les classes et les limites trouvées, passe en revue cette liste. Chaque ligne a déjà caché un bug dans un projet d'étudiant :

Exercices

test('test retard', () => {
  expect(joursDeRetard('2027-03-14', '2027-03-17')).toBe(3);
  const r = joursDeRetard('2027-03-14', '2027-03-14');
  expect(r).toBe(0);
});

test('compte les jours après le retour prévu', () => {
  const retourPrevu = '2027-03-14';
  const aujourdhui = '2027-03-17';

  const retard = joursDeRetard(retourPrevu, aujourdhui);

  expect(retard).toBe(3);
});

test('vaut 0 le jour du retour prévu', () => {
  const retourPrevu = '2027-03-14';

  const retard = joursDeRetard(retourPrevu, retourPrevu);

  expect(retard).toBe(0);
});

test('une période qui commence le dernier jour chevauche', () => {
  const pc07 = { debut: '2027-03-10', fin: '2027-03-14' };

  expect(periodesSeChevauchent(pc07, { debut: '2027-03-14', fin: '2027-03-18' })).toBe(true);
});

export function estEnRetard(pret) {
  const aujourdhui = new Date().toISOString().slice(0, 10);
  return aujourdhui > pret.fin;
}

test("un prêt qui finit le 30 mars n'est pas en retard", () => {
  expect(estEnRetard({ fin: '2027-03-30' })).toBe(false);
});

export function estEnRetard(pret, aujourdhui) {
  return aujourdhui > pret.fin;
}

test("un prêt n'est pas en retard le jour de son retour", () => {
  expect(estEnRetard({ fin: '2027-03-30' }, '2027-03-30')).toBe(false);
});

test('un prêt est en retard le lendemain de son retour', () => {
  expect(estEnRetard({ fin: '2027-03-30' }, '2027-03-31')).toBe(true);
});