Cinq fichiers de tests, cinq styles différents : ici des doublures natives de PHPUnit, là Mockery, ailleurs aucune assertion sur les cas d’erreur. C’est le constat dressé lors d’une revue de code approfondie dans une structure qui développe des extensions pour plusieurs clients, où chaque développeur teste visiblement à sa propre façon, du moment que la pipeline passe au vert.
Un document de stratégie de tests existait pourtant, rédigé un an plus tôt et rangé dans le wiki interne. Le problème n’était pas son contenu, globalement raisonnable, mais son destin : personne ne l’ouvrait plus depuis sa rédaction. Un document de gouvernance qui n’est pas relu régulièrement finit par ne plus gouverner grand-chose.
Pourquoi un document de stratégie s’use plus vite qu’on ne le pense
Un texte rédigé une fois, validé en réunion, puis archivé, subit le même sort que n’importe quelle documentation statique : le projet évolue, de nouveaux outils arrivent, de nouveaux développeurs rejoignent l’équipe sans jamais avoir participé à sa rédaction initiale, et le texte devient progressivement une photographie d’un état passé plutôt qu’un guide pour l’avenir.
Le vrai enjeu n’est donc pas d’écrire un bon document une fois, mais de construire un mécanisme qui l’oblige à rester pertinent.
Réduire le document à l’essentiel, quatre pages au maximum
Un document de trente pages ne sera jamais relu en entier par un développeur pressé. La stratégie tient sur quatre pages, organisées en sections courtes et concrètes :
- Quels types de tests sont attendus pour quel type de code (logique métier, contrôleur REST, gabarit d’affichage).
- Quelle bibliothèque de doublures de test utiliser dans quel contexte, avec un exemple de code pour chacune.
- Quel seuil de couverture minimal s’applique, et à quelles exceptions documentées.
- Quelle est la procédure quand un test devient instable ou trop lent.
Un exemple concret vaut mieux qu’une règle abstraite
Plutôt que d’écrire « préférez les doublures natives de PHPUnit à Mockery sauf cas justifié », le document montre le code correspondant, directement copiable :
// Préféré : doublure native PHPUnit
$service = $this->createMock( Service_Facturation::class );
$service->method( 'calculer_total' )->willReturn( 42.0 );
// Réservé aux cas où l'ordre d'appel compte
$service = Mockery::mock( Service_Facturation::class );
$service->shouldReceive( 'calculer_total' )
->once()
->ordered()
->andReturn( 42.0 );
Transformer les règles en vérifications automatiques
Une règle écrite mais non contrôlée reste une intention. Chaque fois qu’une règle du document peut être vérifiée par un outil, elle doit l’être : un seuil de couverture minimal se contrôle avec l’option --coverage-clover de PHPUnit lue en CI, une convention de nommage de méthode de test se contrôle avec une règle PHPCS personnalisée. Ce qui n’est pas vérifiable automatiquement doit être signalé comme tel dans le document, pour rester honnête sur ses propres limites.
Désigner un propriétaire, pas un comité
Un document sans propriétaire clair devient un texte dont la mise à jour n’est la responsabilité de personne. Un développeur, désigné pour une durée de six mois renouvelable, porte la responsabilité de proposer les mises à jour lorsqu’un nouvel outil est adopté ou qu’une règle s’avère inadaptée en pratique. Ce rôle n’exige pas de trancher seul : il s’agit de porter le sujet en revue d’équipe, pas de l’imposer.
Un document de gouvernance sans propriétaire ressemble à un jardin sans jardinier : il pousse encore un peu, puis il se fige.
L’inscrire dans le rituel de revue de code
Le changement le plus efficace observé dans cette agence n’a pas été une réécriture du contenu, mais un ajout au modèle de pull request : une case à cocher demandant explicitement si les tests ajoutés respectent le document de stratégie, avec un lien direct vers celui-ci. Ce simple rappel, répété à chaque contribution, a suffi à ramener le document dans le champ de vision quotidien de l’équipe, là où il avait disparu pendant des mois.
Prévoir une relecture calendaire, pas seulement événementielle
Au-delà des mises à jour ponctuelles, une relecture complète du document est planifiée deux fois par an, lors d’une réunion dédiée d’une heure où chaque section est discutée collectivement. Cette relecture régulière, même quand rien ne semble avoir changé, évite que le document ne devienne obsolète sans que personne ne s’en aperçoive.
En résumé
Un document de stratégie de tests ne vaut que par les mécanismes qui le maintiennent vivant : sa brièveté, ses règles vérifiables automatiquement, un propriétaire identifié et sa présence dans le rituel de revue de code. Sans ces mécanismes, même le texte le mieux rédigé finit archivé, et chacun revient à tester à sa façon.
