Transformer un bug en test de régression

Objectif

Chaque bug confirmé laisse derrière lui un contrôle automatique durable, qui atteste la correction et rend le bug immédiatement de nouveau visible lors d'une modification ultérieure.

Prérequis

Un rapport de bug avec des étapes reproductibles, le résultat attendu et le résultat réel ; une suite de tests qui s'exécute localement et en intégration continue.

Étapes

1. Reproduire une fois à la main pour confirmer le rapport et apprendre les conditions minimales : quelle entrée, quel état, quel ordre ?
2. Choisir le niveau le plus bas où le bug se manifeste encore : test unitaire si une fonction calcule mal ; test d'intégration s'il faut la base de données ou la couche HTTP. Plus le niveau est bas, plus le test est rapide et stable.
3. Nommer le test d'après le comportement et noter le numéro du rapport dans le docstring ou en commentaire : test_export_akzeptiert_umlaute_im_dateinamen avec renvoi vers le ticket.
4. Exécuter le test et vérifier qu'il échoue pour la raison signalée — pas à cause d'une faute de frappe dans le test ou de données de test manquantes. Un test qui n'a jamais été rouge ne prouve rien.
5. Corriger jusqu'à ce que le test soit vert ; ne rejouer d'abord que ce test (pytest : --lf, ou --last-failed, réexécute les derniers tests en échec), puis toute la suite contre les effets de bord.
6. Déposer le test et la correction dans le même commit, avec renvoi vers le rapport ; l'historique relie ainsi symptôme et cause, et un futur git bisect retrouve les deux.
7. Si la correction est différée : intégrer quand même le test et le marquer avec @pytest.mark.xfail(strict=True, reason="Ticket 4711"). Il s'exécute avec les autres et est considéré comme devant échouer ; dès qu'il réussit de façon inattendue (XPASS), la suite se déclenche — le bug a alors disparu silencieusement, et le ticket mérite qu'on y regarde.

Résultat attendu

La suite de tests croît le long de l'historique réel des bugs du système plutôt que le long de cas imaginés ; un retour en arrière sur la correction est détecté en intégration continue, pas du côté de la clientèle.

Limites et base de vérification

Les bugs liés au temps, à la charge ou à la concurrence ne peuvent souvent pas être reproduits de façon déterministe ; on écrit alors le contrôle reproductible le plus proche possible et on note la lacune dans le rapport. Un test de régression instable n'est pas calmé à coups de répétitions, mais réparé ou mis de côté en xfail avec justification. Les options de pytest suivent la documentation citée ; la démarche elle-même est une recommandation de pratique, sans mesure.