Quels tests écrire sur un projet existant ?

Choisir le comportement à protéger

Lorsqu’un projet possède peu de tests, vouloir couvrir tout le code d’un seul mouvement peut disperser l’effort. Je propose de commencer par une question : quel comportement serait coûteux à casser lors du prochain changement ? Si un formulaire perd la saisie après une erreur réseau, on dispose déjà d’un cas précis à protéger.

La couverture indique quelles lignes ont été exécutées pendant les tests. Elle ne dit pas, à elle seule, si les assertions protègent le bon résultat. Une suite peut traverser une fonction sans vérifier l’erreur qui gêne réellement les utilisateurs. Le comportement attendu doit donc être formulé avant de choisir le fichier à tester.

Choisir une frontière qui reste utile

• Une règle pure : vérifier ses entrées, ses sorties et les cas limites du métier.
• Un formulaire : vérifier la saisie, les erreurs et le résultat visible après validation.
• Un échange entre services : vérifier le contrat, les réponses d’erreur et les données transmises.
• Un parcours critique : vérifier que les étapes essentielles fonctionnent ensemble.

Ces niveaux se complètent. Un test de règle métier peut expliquer précisément pourquoi un calcul est faux. Un test de parcours peut révéler que le bouton n’appelle plus ce calcul. Le bon choix dépend de la panne que l’on souhaite détecter et du coût de préparation du scénario. Réutiliser les outils du dépôt évite d’ajouter une infrastructure pour un seul cas.

Rendre le scénario explicite

Un scénario lisible précise la situation initiale, l’action et le résultat attendu. Les données doivent expliquer le cas sans dépendre d’un service réel ou d’un ordre d’exécution implicite. Lorsque le temps intervient, une date fixée dans le test rend la vérification reproductible.

import assert from "node:assert/strict";
import { test } from "node:test";

test("une page suivante conserve la catégorie", () => {
  const params = new URLSearchParams({
    categorie: "conseils",
    page: "2",
  });

  assert.equal(params.get("categorie"), "conseils");
  assert.equal(params.get("page"), "2");
});

Cet exemple illustre la forme d’une assertion. Dans un projet, le test devrait appeler la fonction qui construit réellement l’URL ou cliquer sur le lien rendu. Tester uniquement des données fabriquées dans le test, comme ici, ne protège pas l’application. C’est la connexion avec le comportement réel qui donne sa valeur à la vérification.

Vérifier que le test sait échouer

Avant de conclure, modifier temporairement le comportement visé permet de vérifier que le test le détecte. Si la catégorie disparaît d’un lien et que la suite reste verte, la protection est insuffisante. Il faut ensuite rétablir le code et relancer la vérification. Ce contrôle simple évite de confondre une suite qui s’exécute avec une suite qui protège.