# Passer d’aucun test à une suite minimale quand l’équipe double en un an

> Une petite structure qui double ses effectifs en un an sans jamais avoir écrit de test automatisé doit avancer vite, sans pour autant arrêter le développement de fonctionnalités.

- Auteur : Clément Hadrot
- Publié le : 2026-05-13
- Mis à jour le : 2026-05-13
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/passer-aucun-test-suite-minimale-equipe-double/

## L’essentiel

- Introduire des tests sans imposer une pause de développement
- Commencer par les fonctions les plus critiques, jamais par une couverture large et superficielle
- Fixer une règle simple pour tout code nouveau, sans exiger la même rigueur sur l'existant

Lire et deviner plutôt que lire et vérifier : voilà comment chaque nouveau développeur comprenait le comportement du code dans une petite structure éditant une extension de gestion de formations en ligne, faute du moindre test automatisé pour le documenter. Ce mode de fonctionnement tenait tant que l'équipe restait restreinte ; il est devenu intenable en passant de trois à sept développeurs en un an, une croissance qui a rendu visible un problème resté longtemps sans conséquence.

Arrêter le développement de fonctionnalités pendant plusieurs semaines pour écrire une suite de tests complète n'était pas une option acceptable pour l'activité. La solution retenue a consisté à introduire des tests de façon incrémentale, sans jamais interrompre la livraison de nouvelles fonctionnalités.

## Choisir un point de départ minuscule mais critique

Plutôt que de viser une couverture large dès le départ, ce qui aurait dilué l'effort sur des zones peu risquées, le choix s'est porté sur la fonction la plus critique et la plus redoutée de toute l'équipe : le calcul de progression d'un apprenant dans un parcours de formation, dont dépendait directement la délivrance d'une attestation de fin de formation. Une seule fonction, testée en profondeur, valait mieux qu'une dizaine de tests superficiels répartis sans logique.

```
public function test_progression_ne_recule_jamais_meme_apres_reprise_module() {
    $apprenant = $this->creer_apprenant_avec_modules_valides( 3 );
    $progression_avant = calculer_progression( $apprenant );

    reprendre_module_deja_valide( $apprenant, $module_id = 2 );
    $progression_apres = calculer_progression( $apprenant );

    $this->assertGreaterThanOrEqual( $progression_avant, $progression_apres );
}
```

### Fixer une règle simple pour le code nouveau uniquement

Exiger une couverture de test rétroactive sur l'ensemble du code existant aurait ralenti l'équipe sans bénéfice immédiat proportionné. La règle adoptée porte uniquement sur le code nouveau, formulée de façon volontairement simple pour rester applicable sans discussion permanente :

- Toute fonction touchant au calcul de progression, à la facturation ou à la délivrance d'attestation doit s'accompagner d'au moins un test au moment de sa création ou de sa modification.
- Le reste du code peut continuer à évoluer sans exigence de test, en attendant une couverture progressive future.
- Aucune pull request touchant ces trois zones n'est fusionnée sans qu'un test correspondant n'apparaisse dans le diff.

## Mesurer la progression sans viser un chiffre arbitraire

Plutôt que de fixer un objectif de couverture de code global, souvent démotivant quand il reste très bas pendant longtemps, l'équipe a suivi un indicateur différent : le nombre de fonctions critiques identifiées comme telles et désormais couvertes par au moins un test, sur un total de douze fonctions listées collectivement dès le premier mois.

| Mois | Fonctions critiques couvertes | Sur un total de |
| --- | --- | --- |
| 1 | 1 | 12 |
| 4 | 5 | 12 |
| 9 | 10 | 12 |

> L'essentiel à retenir : Introduire des tests sans imposer une pause de développement ; Commencer par les fonctions les plus critiques, jamais par une couverture large et superficielle ; Fixer une règle simple pour tout code nouveau, sans exiger la même rigueur sur l'existant

## Ce qui a facilité l'adoption par les nouveaux arrivants

Un nouveau développeur rejoignant l'équipe en cours d'année a bénéficié d'un effet inattendu mais logique : les fonctions déjà couvertes par un test devenaient les plus faciles à comprendre, le test lui-même servant de documentation vivante du comportement attendu. Cet effet a renforcé naturellement l'adhésion à la règle, sans qu'aucune contrainte hiérarchique n'ait eu besoin de l'imposer davantage.

> Une suite de tests qui grandit fonction critique par fonction critique, plutôt que fichier par fichier au hasard, raconte une histoire cohérente à chaque nouvel arrivant : voici ce que l'équipe a jugé trop important pour se permettre de casser sans s'en rendre compte.

## Notre verdict

Passer d'aucun test à une suite minimale pendant une phase de forte croissance des effectifs fonctionne mieux en ciblant d'abord les quelques fonctions dont une régression coûterait le plus cher, plutôt qu'en cherchant une couverture large et superficielle. Cette approche progressive, appliquée uniquement au code nouveau et aux zones critiques identifiées collectivement, a permis à cette structure de continuer à livrer des fonctionnalités tout en construisant, mois après mois, un filet de sécurité qui n'existait pas un an plus tôt.