« @group skip » : cette simple annotation, ajoutée un vendredi après-midi sur un test qui échouait de façon aléatoire, s’est retrouvée quatorze mois plus tard toujours présente dans le code, aux côtés de treize autres annotations similaires accumulées au fil du temps. Aucune d’entre elles ne portait la moindre indication sur la raison du skip, ni sur une date à laquelle le sujet devait être réexaminé.
Un skip est un outil légitime face à un test réellement instable qu’on ne peut pas corriger dans l’instant. Le problème n’est pas son usage, mais son absence de suivi : sans mécanisme qui force à y revenir, un skip devient silencieusement permanent, et la couverture de test qu’il représentait disparaît sans que personne ne le décide explicitement.
Pourquoi un skip simple échoue à rester temporaire
Un skip ajouté sans contexte ne laisse aucune trace exploitable : ni la raison de l’instabilité, ni la personne à qui poser la question, ni une échéance qui obligerait à reconsidérer la décision. Il devient invisible dans les rapports habituels, qui affichent généralement les tests ignorés comme une simple statistique agrégée plutôt que comme une liste nominative consultée régulièrement.
Structurer une quarantaine plutôt qu’un skip nu
La quarantaine reprend le même mécanisme technique qu’un skip, mais l’enrichit systématiquement de métadonnées obligatoires, portées directement par une annotation PHPDoc au-dessus de la méthode de test :
/**
* @quarantaine
* raison: échec intermittent lié à l'ordre d'exécution avec test_creation_compte
* ouvert-par: equipe-facturation
* date-limite: 2026-03-01
*/
public function test_calcul_prorata_changement_abonnement() {
$this->markTestSkipped( 'En quarantaine, voir annotation ci-dessus.' );
}
Ces métadonnées, bien que non lues automatiquement par PHPUnit lui-même, sont exploitées par un script d’audit dédié qui parcourt la suite avant chaque exécution de la pipeline.
Faire échouer la pipeline sur une quarantaine expirée
Le script d’audit compare la date limite indiquée à la date du jour et fait échouer explicitement la pipeline si une quarantaine a dépassé son échéance sans avoir été traitée :
php bin/verifier-quarantaines.php --suite=tests/
# Erreur : test_calcul_prorata_changement_abonnement
# quarantaine expirée depuis le 2026-03-01, aucune décision prise.
Cette échéance force une décision explicite : corriger le test, le supprimer si le comportement qu’il vérifiait n’a plus lieu d’être, ou prolonger la quarantaine avec une nouvelle date et une justification écrite du délai supplémentaire.
Garder la quarantaine visible dans les rapports
Contrairement à un skip classique noyé dans les statistiques globales, chaque test en quarantaine apparaît nommément dans un rapport dédié, généré à chaque exécution et partagé avec l’équipe concernée par sa raison d’ouverture :
| Test | Raison | Échéance | Jours restants |
|---|---|---|---|
| test_calcul_prorata_changement_abonnement | Ordre d’exécution | 2026-03-01 | 46 |
| test_notification_relance_impaye | Dépendance réseau non simulée | 2026-02-10 | 27 |
Réexaminer plutôt que reconduire par habitude
Une quarantaine reconduite systématiquement sans effort réel de correction reproduit exactement le problème du skip permanent, simplement avec plus de paperasse. La règle adoptée limite à deux le nombre de prolongations possibles avant qu’une décision définitive ne soit exigée en réunion d’équipe : corriger, supprimer, ou documenter formellement pourquoi le comportement testé n’est plus pertinent.
- Première quarantaine : trente à quarante-cinq jours, temps raisonnable pour investiguer.
- Première prolongation : justification écrite obligatoire.
- Seconde prolongation : décision arbitrée collectivement, pas laissée à la seule personne qui a ouvert la quarantaine.
Un test ignoré sans échéance n’est pas mis de côté, il est abandonné sans que personne ne l’ait décidé. La quarantaine rend cet abandon visible, ou l’empêche.
En résumé
La différence entre un skip et une quarantaine tient presque entièrement à la traçabilité et à l’échéance. En documentant la raison, en fixant une date de réexamen et en gardant chaque test concerné visible dans un rapport dédié, une équipe évite l’accumulation silencieuse de tests désactivés qui, comme dans ce cas, finit par représenter plus d’un an de couverture perdue sans qu’aucune décision consciente n’ait jamais été prise.
