23. La non-régression : transformer les incidents en contraintes utiles
Pourquoi ce chapitre existe
Une non-régression est souvent comprise comme « ajouter le test qui reproduit le bug ». Cette réponse est nécessaire quand le comportement fautif est connu, mais elle reste trop étroite si elle n'examine pas pourquoi l'écart a pu traverser la conception, la revue, la CI et l'exploitation. Les incidents ne sont pas seulement des défauts à colmater : ils révèlent quelles attentes du système sont restées sans protection.
Les idées essentielles
- Une non-régression protège une attente identifiée, pas uniquement le scénario exact d'un incident.
- Les défauts issus de données, de configuration, de contrats ou de déploiement appellent souvent une barrière différente d'un test unitaire.
- Un correctif doit inclure la preuve du comportement restauré et, lorsque nécessaire, la réparation des effets déjà produits.
- Les suites de régression doivent rester intentionnelles ; accumuler tous les scénarios sans structure les rend lentes et opaques.
Partir du mécanisme de défaillance
Après un incident, reconstruire l'attente violée, les conditions qui l'ont rendue possible et les barrières qui n'ont pas suffi. Un calcul erroné peut appeler un invariant. Un événement perdu peut appeler une garantie de publication et une réconciliation. Une permission contournée peut appeler une décision d'autorisation centralisée. Une alerte ignorée peut appeler un signal plus actionnable plutôt qu'un test de plus.
| Mécanisme observé | Barrière possible |
|---|---|
| Cas limite d'une règle | Cas de décision, propriété ou invariant |
| Données inattendues | Contrainte, validation, test de migration, rapprochement |
| Contrat incompatible | Test de contrat et transition versionnée |
| Configuration ou déploiement | Validation de configuration, canari, métrique de santé |
| Échec silencieux | Instrumentation, alerte et procédure de reprise |
Préserver les comportements legacy sans les sanctuariser
Les systèmes anciens contiennent des comportements non documentés, parfois nécessaires, parfois simplement accidentels. Les tests de caractérisation permettent de les rendre visibles avant une modification. Ils ne signifient pas que tout comportement existant doit vivre éternellement. Ils créent le choix : conserver, corriger avec une migration explicite, ou déprécier après avoir identifié les utilisateurs affectés.
Le scénario observé montre une manière dont le système a échoué. La règle à protéger peut être plus générale, et le cas corrigé peut nécessiter une réparation métier au-delà du code. Écrire l'invariant empêche de surajuster la solution au seul exemple connu.
Anti-patterns
Empiler les tests de bug au même niveau
Chaque incident ajoute un test de parcours lent jusqu'à ce que la suite ralentisse toute livraison. Réexaminer le niveau de preuve peut révéler qu'une contrainte locale, un contrat ou un contrôle de donnée est plus précis et moins coûteux.
Corriger le futur sans traiter le passé
Un correctif peut empêcher les nouvelles écritures erronées tout en laissant des milliers d'enregistrements invalides. L'analyse doit distinguer prévention, détection et réparation des états déjà affectés.
Supprimer un test parce qu'il semble redondant
Deux tests semblables peuvent protéger des propriétés distinctes. Avant de supprimer, nommer l'attente de chacun et vérifier que la preuve restante échoue réellement lorsque cette attente est violée.
Bonnes pratiques
Associer le correctif à une trace d'apprentissage
Un incident significatif devrait produire un lien entre l'attente, la barrière ajoutée ou modifiée, la réparation et le signal qui permettra de vérifier l'amélioration. Cette trace peut rester courte ; elle évite de répéter les mêmes discussions quand le contexte disparaît.
Revoir périodiquement la suite de régression
Identifier les tests instables, lents, dupliqués ou dont personne ne comprend plus le risque. Les réparer, déplacer ou retirer est une activité de qualité. Une suite saine augmente la confiance ; une suite opaque devient un coût qui encourage les contournements.
Checklist — Une non-régression traite-t-elle vraiment l'écart ?
- Quelle attente a été violée et quel dommage en a résulté ?
- Quel mécanisme a rendu l'erreur possible et quelle barrière peut le traiter le plus tôt ?
- La preuve protège-t-elle l'invariant ou seulement l'exemple observé ?
- Les données ou effets produits avant le correctif demandent-ils une réparation ?
- Comment vérifierons-nous que la nouvelle barrière fonctionne en pratique ?
- Le test ajouté a-t-il un nom et un niveau qui expliquent sa place ?
À retenir
La non-régression est une discipline d'apprentissage. Elle transforme un écart réel en contrainte, preuve ou signal qui protège une famille de comportements, plutôt qu'en accumulation mécanique de scénarios de bugs.