L’article propose d’utiliser OpenTelemetry pour surveiller et optimiser les tests PHPUnit, face à des problèmes de mémoire ou de temps d’exécution croissants dans des projets en expansion. L’idée est d’appliquer les mêmes principes d’observabilité que pour les applications en production, afin d’identifier les tests les plus gourmands en ressources grâce à des traces et métriques collectées.
Pour cela, l’auteur recommande l’extension phpunit-telemetry-bridge, compatible avec OpenTelemetry, qui s’intègre facilement via Composer et se configure dans le fichier PHPUnit. Une fois activée, elle génère des données détaillées sur chaque test (durée, mémoire, statut), exportables vers un backend OTLP pour analyse.
L’outil est particulièrement utile pour les grandes suites de tests, où son surcoût devient justifié. L’article inclut un exemple de configuration et un lien vers un dépôt démonstratif, tout en soulignant la nécessité d’évaluer son utilité selon l’envergure du projet.
L'article présente une liste de conseils pour les tests avec PHPUnit, certains spécifiques à Laravel et d'autres non. J'en retiens :
- assertEqualsCanonicalizing qui permet de vérifier que 2 tableaux sont "égaux", sans tenir compte de l'ordonnancement des valeurs
- l'attribut #[\PHPUnit\Framework\Attributes\DoesNotPerformAssertions] qui permet de dire à PHPUnit qu'un test ne vérifie aucune assertion (ce qui déclenche normalement une erreur dans PHPUnit)
- l'attribut #[\PHPUnit\Framework\Attributes\RunInSeparateProcess] permet de préciser à PHPUnit d'exécuter les tests dans plusieurs processus... ça permet par exemple de définir une même constante dans 2 méthodes de tests de la même classe.
- la méthode $this->markTestSkipped('test are skipped because ...'); permet de sauter l'exécution d'un test, $this->markTestIncomplete('test are incomplete but not in error'); permet d'indiquer qu'un test est incomplet (??) et $this->fail('test are failed !'); permet de marquer un test comme échoué quoi qu'il arrive.
- phpunit --order-by=random permet de lancer les tests dans un ordre aléatoire - c'est très pratique pour détecter les dépendances implicites entre les tests. phpunit --order-by=random --random-order-seed=1234 permet même de rejouer le même ordre aléatoire, notamment pour reproduire un échec.
- phpunit --stop-on-failure --stop-on-error permet de stopper l'exécution des tests dès la première erreur rencontrée
- enfin en utilisant l'attribut #[\PHPUnit\Framework\Attributes\Group('mon_super_groupe')], on peut exclure les tests de ce groupe vendor/bin/phpunit --exclude-group mon_super_groupe ou au contraire ne jouer que les tests de ce groupe vendor/bin/phpunit --group flaky
L'auteur se place dans le contexte d'une application Symfony avec des tests PHPUnit et en fournissant des jeux de données via Foundry. Il montre l'utilisation du trait ClockAwareTrait et composant Clock. Enfin, il rappelle que PHP-FIG a proposé la PSR-20 Clock qui dispose de plusieurs implémentations, dont le composant Clock.
Tout est dans le titre
Tout est dans le titre, sauf que ça concerne PHPUnit, Doctrine, Symfony et Laravel
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Une astuce en attendant une meilleure intégration
Tout est dans le titre
Bon à savoir
L'auteur effectue le refactoring d'un test en appliquant plusieurs techniques / idées pour le rendre plus lisible.... très intéressant
Tout est dans le titre
Tout est dans le titre
Il s'agit de pouvoir faire des tests unitaires avec des opérations sur le système de fichiers, via PHPUnit. L'auteur montre l'utilisation de https://github.com/bovigo/vfsStream/ qui permet de créer un système virtuel : pratique en cas de plantage de la suite de tests par exemple, pas besoin de faire le ménage ^^
Penser à mettre force="true" dans le fichier phpunit.xml.dist ( <env name="APP_ENV" value="test" force="true" /> )
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre