Tests de non-régression : définition, méthode et exemples

Une régression est un défaut qui apparaît dans une fonctionnalité qui marchait, à la suite d'une modification du logiciel : une correction, une évolution, une mise à jour de bibliothèque. Le test de non-régression consiste à rejouer, après chaque modification, les tests qui passaient avant, pour vérifier que rien n'a été cassé. On dit aussi test de régression : les deux expressions désignent la même chose, l'une insiste sur la recherche des régressions, l'autre sur leur absence. Ce chapitre montre comment construire une suite de non-régression, corriger un bug sans en créer d'autres, et retrouver le commit qui a introduit une régression.

Pourquoi les régressions arrivent

Un programme est un réseau de dépendances. Modifier un endroit peut avoir des effets ailleurs, que personne ne voit en écrivant la modification.

Le point commun : la personne qui fait la modification ne pense pas à vérifier ce qu'elle ne savait pas avoir touché. C'est pour cela que la non-régression doit être systématique et automatisée, et non laissée à l'intuition.

La suite de non-régression

Une suite de non-régression n'est pas un type de test à part : c'est l'ensemble des tests existants, que l'on rejoue après chaque modification. Elle grossit de deux façons :

1. Avec le développement : chaque fonctionnalité arrive avec ses tests unitaires, d'intégration et parfois de bout en bout ;
2. Avec les bugs : chaque défaut corrigé arrive avec le test qui l'aurait détecté. Il porte souvent le numéro du ticket dans son nom.

Plus le projet vit, plus la suite protège. Une application de trois ans, dont chaque bug corrigé a laissé un test, ne peut presque plus régresser sur ses anciens défauts.

Corriger un bug avec un test de non-régression

Reprenons l'histoire du chapitre 1. Le ticket n° 31 arrive : « PC-07 a été réservé par Julie du 10 au 14 mars et par Sofiane du 14 au 18 mars. » La méthode tient en cinq étapes.

1. Reproduire le bug dans un test, et le voir échouer. Avant de toucher au code, on écrit le test qui décrit le comportement attendu.

// src/regles.test.js, dans le describe de periodesSeChevauchent
test('ticket 31 : 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);
});

Lancé sur le code de Yanis (avec < au lieu de <= dans la seconde comparaison), il échoue : expected false to be true. Le bug est reproduit : on sait exactement ce qui ne va pas, et on saura quand c'est corrigé.

2. Corriger la cause. On remet numeroDeJour(b.debut) <= numeroDeJour(a.fin). Et on règle le vrai besoin de Karim autrement, avec la logistique : une demi-journée de battement n'est pas une affaire de comparaison de dates, c'est une nouvelle règle à spécifier.

3. Voir le test passer. Le test du ticket 31 est vert.

4. Rejouer toute la suite. npm test : tous les tests passent, y compris ceux des autres fonctions. C'est le test de non-régression au sens strict : la correction n'a rien cassé ailleurs.

5. Livrer avec la trace. Le commit cite le ticket (Corrige le chevauchement des périodes contiguës (ticket 31)), le test reste dans la suite pour toujours, et le ticket est clos avec le lien vers le correctif.

Le cours Maintenance applicative détaille cette démarche, avec la branche de correctif, la recherche de la cause et la livraison (corriger un bug sans régression).

Quoi rejouer, et quand

Rejouer tous les tests à chaque modification est l'idéal, tant que c'est rapide. Quand la suite grossit, on organise les rejeux selon leur coût :

Quand on ne peut pas tout rejouer (une campagne manuelle, par exemple), on sélectionne les tests par risque : d'abord les fonctions touchées par la modification et celles qui en dépendent, puis les fonctions critiques pour le métier (réserver, enregistrer une sortie), puis le reste si le temps le permet.

La campagne de non-régression en recette

Une partie des vérifications reste manuelle : l'ergonomie, les impressions, les envois de courriels réels sur l'environnement de recette. Pour ne rien oublier d'une version à l'autre, on tient une liste de non-régression : les scénarios critiques rejoués avant chaque mise en production, quelle que soit la modification.

La colonne de chaque version garde la mémoire des campagnes ; un KO renvoie vers une fiche d'anomalie. Les scénarios qui reviennent à chaque version et ne demandent pas de jugement humain sont les premiers à automatiser : NR-03 et NR-04 sont déjà couverts par les tests d'intégration du chapitre 8. Le chapitre 14 montre comment rédiger ces cas et le rapport de la campagne.

Les tests d'instantané et la non-régression visuelle

Un test d'instantané (snapshot test) enregistre la sortie d'une fonction ou d'un composant lors du premier lancement, puis vérifie aux lancements suivants qu'elle n'a pas changé. C'est une forme de non-régression : il ne dit pas si la sortie est juste, seulement si elle est identique.

test("le motif de refus garde son format", () => {
  const resultat = verifierReservation(
    { materiel: 'PC-07', debut: '2027-03-12', fin: '2027-03-18' },
    [{ materiel: 'PC-07', debut: '2027-03-10', fin: '2027-03-14' }],
    '2027-03-08',
  );

  expect(resultat).toMatchInlineSnapshot();
});

Au premier lancement, Vitest écrit la valeur obtenue dans le fichier de test, à l'intérieur des parenthèses :

  expect(resultat).toMatchInlineSnapshot(`
    {
      "acceptee": false,
      "motif": "PC-07 est déjà réservé du 10/03/2027 au 14/03/2027.",
    }
  `);

Si Lina change plus tard formaterDate, le test échoue et montre la différence. Si le changement est voulu, on met à jour les instantanés avec npx vitest run -u. toMatchSnapshot(), sans « Inline », range les instantanés dans un dossier __snapshots__ à côté du fichier de test.

Playwright propose la même idée pour l'apparence : await expect(page).toHaveScreenshot() compare une capture de la page à une capture de référence, au pixel près (avec une tolérance réglable). C'est la non-régression visuelle : elle détecte un bouton qui disparaît ou une mise en page cassée par une modification CSS.

Les mises à jour de dépendances

Les bibliothèques d'un projet évoluent, et les mettre à jour corrige des failles de sécurité. Mais chaque mise à jour peut introduire une régression. La suite de non-régression rend ces mises à jour sûres : un outil comme Dependabot ou Renovate ouvre une pull request pour chaque nouvelle version, la CI rejoue la suite, et l'équipe fusionne si tout est vert. Sans tests, on n'ose plus mettre à jour, et l'application accumule des dépendances vulnérables. Le cours Maintenance applicative traite ce sujet (versions et dépendances).

Retrouver le commit fautif avec git bisect

Une régression est signalée, mais personne ne sait quand elle est apparue : la version 1.2 marchait, la version actuelle non, et cent commits les séparent. git bisect fait une recherche dichotomique dans l'historique : il te place au milieu, tu dis si le défaut est présent, il coupe en deux la moitié restante, et ainsi de suite. Pour cent commits, sept étapes suffisent (2⁷ = 128).

Avec un test qui reproduit le défaut, la recherche est entièrement automatique :

git bisect start
git bisect bad                 # le commit actuel a le défaut
git bisect good v1.2.0         # cette version ne l'avait pas
git bisect run npx vitest run src/ticket31.test.js
git bisect reset               # revenir à la branche de départ

git bisect run lance la commande à chaque étape : un code de retour 0 (tests verts) signifie « bon », un autre code (tests rouges) signifie « mauvais ». À la fin, Git affiche le premier commit fautif, son auteur et son message. Ici, src/ticket31.test.js contient le test du ticket 31 et n'est pas commité pendant la recherche. Le test doit exister dans toutes les versions testées : c'est pour cela qu'on l'écrit dans un fichier non suivi par Git, que les changements de commit ne touchent pas.

Exercices

export function dureeEnJours(debut, fin) {
  return new Date(fin).getDate() - new Date(debut).getDate() + 1;
}

test('ticket 23 : refuse un prêt de 16 jours à cheval sur deux mois', () => {
  const demande = { materiel: 'VP-02', debut: '2028-02-25', fin: '2028-03-11' };

  expect(verifierReservation(demande, [], '2028-02-01').motif).toBe('Un prêt dure au plus 15 jours.');
});

test('accepte un prêt de 15 jours à cheval sur deux mois', () => {
  const demande = { materiel: 'VP-02', debut: '2028-02-26', fin: '2028-03-11' };

  expect(verifierReservation(demande, [], '2028-02-01').acceptee).toBe(true);
});