Recette d'une étape

Le typecheck ne prouve rien sur le comportement. Les tests unitaires prouvent que les morceaux fonctionnent isolément. Une étape n'est finie que lorsque l'application, réellement démarrée, répond ce qu'on attend.

Cette procédure existe pour empêcher trois choses précises, dans l'ordre de fréquence : déclarer une étape finie parce que ça compile, lire un résultat et se convaincre qu'il était attendu, et corriger l'attente au lieu du code.

1. Écrire les cas AVANT de lancer

Lister ce que l'étape devait livrer, et pour chaque cas noter le résultat attendu avant d'exécuter la moindre commande.

C'est l'étape que tout le monde saute, et c'est la seule qui compte. Une fois qu'on a vu la réponse, on ne peut plus juger honnêtement si elle est correcte : on la trouve plausible, ce qui n'est pas la même chose.

Toujours couvrir ces quatre familles :

La quatrième famille est celle qu'on oublie, et celle qui casse en production.

Format d'un cas :

CAS 3 — identifiant dont la clé de contrôle est fausse
  curl -s -w "\n[%{http_code}]" -X POST localhost:3000/verifier -d '...'
  ATTENDU : 400, corps contenant « n'est pas valide », aucun appel au service externe

2. Démarrer l'application

docker compose up -d --build
until curl -sf localhost:3000/api/sante >/dev/null; do sleep 1; done

Attendre la sonde de vivacité plutôt que de dormir un nombre de secondes arbitraire. Et ne jamais recetter sur un build périmé : c'est la première cause de résultat inexplicable — on teste le code d'avant.

3. Lancer et comparer

Un curl par cas. Afficher le code HTTP et le corps : un 200 qui renvoie un corps vide passe pour un succès si on ne regarde que le statut.

curl -s -w "\n[HTTP %{http_code}] %{time_total}s\n" localhost:3000/...

Comparer à l'attendu écrit à l'étape 1, littéralement. « En gros c'est ça » n'est pas un verdict.

4. Itérer jusqu'à 100 %

En cas d'écart : corriger le code, pas l'attendu.

On ne modifie un résultat attendu que si on peut expliquer en une phrase pourquoi l'attente initiale était fausse — et on l'écrit dans le rapport final. Ajuster silencieusement l'attendu pour faire verdir la recette vide la procédure de tout son sens et produit une étape « validée » qui ne marche pas.

Après chaque correction, reprendre au 3 sur la totalité des cas, pas seulement celui qu'on vient de corriger. Une correction en casse une autre plus souvent qu'on ne le croit, et un cas qu'on ne rejoue pas est un cas dont on ne sait plus rien.

5. Clore

Quand tous les cas passent, relancer la vérification statique du projet (typecheck, lint, tests unitaires) : une correction faite dans l'urgence de la recette a pu casser autre chose.

Puis rendre un tableau, sans arrondir :

Terminer par le nombre de cas passés sur le total, les corrections apportées, et ce qui reste en échec s'il en reste.

Ne jamais annoncer une étape terminée avec un cas rouge. Dire lequel, et pourquoi il résiste. Une étape à 6 cas sur 7 est une étape à 6 cas sur 7 : c'est une information utile, « c'est bon » ne l'est pas.

Adapter au projet

Avant la première recette, lister les invariants du projet — les propriétés vraies à chaque appel, quelle que soit la feature — et les vérifier à chaque passage. Ils ne figurent dans aucun cas de test parce qu'ils ne sont propres à aucun ; c'est justement pour ça qu'on ne les vérifie jamais.

Exemples d'invariants qui méritent une ligne de recette :

# Aucune donnée sensible dans les journaux
docker compose logs app | grep -E "<motif à ne jamais voir>"   # doit être vide

# La limitation de débit répond
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code} " localhost:3000/...; done

Les invariants du projet en cours se trouvent dans son CLAUDE.md.

Portée

C'est une aide à la rigueur, pas un filet de sécurité. Elle ne remplace ni les tests automatisés ni une revue : elle empêche seulement de confondre « ça compile » avec « ça marche ».