Sur un projet d’agence gérant une dizaine d’extensions internes partagées entre plusieurs sites clients, la suite de tests avait fini par regrouper unitaires PHPUnit, tests d’intégration avec base de données réelle, et scénarios Playwright bout en bout, le tout dans un seul job CI de onze minutes. Le symptôme le plus révélateur n’était pas la durée en elle-même, mais le changement de comportement de l’équipe : les développeurs avaient cessé de lancer la suite localement avant de pousser, la remettant systématiquement au jugement du pipeline, ce qui retardait la détection des erreurs les plus triviales.
La restructuration en pipeline à deux vitesses n’a rien changé au nombre de tests écrits, seulement à leur organisation et à leur moment d’exécution, avec un effet immédiat sur la discipline de l’équipe.
Le principe : classer par coût, pas par outil
La tentation naturelle est de séparer par technologie : PHPUnit d’un côté, Playwright de l’autre. C’est un mauvais critère, car certains tests PHPUnit d’intégration avec base de données sont plus lents que certains scénarios Playwright ciblés. Le bon critère est le temps d’exécution individuel et la dépendance à des ressources externes (base de données réelle, réseau, navigateur).
tests/
├── unit/ (aucune I/O, aucune base, < 50 ms par test)
├── integration/ (base de données réelle, appels wpdb)
└── e2e/ (navigateur complet, le plus lent)Marquer les groupes avec les annotations PHPUnit
/**
* @group rapide
*/
class Test_Calcul_Remise extends TestCase {
public function test_remise_dix_pourcent_appliquee() {
$this->assertEquals( 90.0, calculer_remise( 100.0, 10 ) );
}
}
/**
* @group lent
*/
class Test_Synchronisation_Stock extends WP_UnitTestCase {
public function test_synchronisation_complete_avec_base_reelle() {
// ...
}
}PHPUnit permet ensuite d’exécuter sélectivement chaque groupe :
vendor/bin/phpunit --group rapide
vendor/bin/phpunit --group lentDeux jobs GitHub Actions en parallèle, pas en série
jobs:
tests-rapides:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: composer install
- run: vendor/bin/phpunit --group rapide
tests-lents:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8.0
steps:
- uses: actions/checkout@v4
- run: composer install
- run: vendor/bin/phpunit --group lent
- run: npx playwright testLes deux jobs démarrent en même temps, sans dépendance de l’un envers l’autre. Le développeur voit le statut du job rapide en moins d’une minute, pendant que le job lent continue en arrière-plan sans bloquer sa perception de « ça marche ou pas ».
Configurer le blocage de merge sur les deux jobs, pas seulement le rapide
Le piège de cette organisation est de configurer la protection de branche pour n’exiger que le job rapide, par facilité, ce qui revient à rendre les tests lents optionnels dans les faits. Les deux jobs doivent rester des vérifications requises dans les réglages de la branche protégée, seule leur exécution est parallélisée, pas leur caractère obligatoire.
- Le job rapide donne un retour immédiat pendant que le développeur est encore concentré sur son changement.
- Le job lent protège contre les régressions plus profondes, sans imposer d’attente avant que le développeur ne passe à autre chose.
- Les deux doivent être verts avant fusion, sans exception tacite pour le job lent « qui prend juste plus de temps ».
Rétablir l’exécution locale rapide
Une fois cette séparation en place côté CI, la même commande vendor/bin/phpunit --group rapide redevient utilisable en local avant chaque commit, puisqu’elle s’exécute en une poignée de secondes. C’est ce retour d’usage local qui a le plus changé l’habitude de l’équipe, davantage que le gain de temps en CI lui-même.
Notre verdict
Cette réorganisation ne change ni les outils ni le nombre de tests, seulement leur découpage et leur ordonnancement. Elle a ramené le retour perçu par un développeur de onze minutes à moins d’une minute pour la majorité de ses changements, tout en conservant une couverture lente complète avant chaque fusion. C’est un chantier d’architecture de CI, indépendant du choix des outils de test eux-mêmes, qui vaut la peine d’être mené dès que la suite dépasse quelques minutes.
