Zéro : c’est le nombre de lignes de log qu’un développeur devrait avoir à faire défiler pour comprendre pourquoi un test a échoué en intégration continue. Dans la réalité, la sortie texte brute de PHPUnit affiche souvent une pile d’appels longue de plusieurs dizaines de lignes, noyée entre les résultats des tests qui passent.
Allure Framework répond à ce problème en transformant les résultats d’exécution en un rapport HTML navigable, avec un historique des tendances d’une exécution à l’autre. Ce billet montre comment brancher Allure sur une suite PHPUnit existante ; il ne traite ni la couverture de code ni les métriques de performance, qui relèvent d’autres outils.
Installer l’adaptateur PHPUnit pour Allure
Allure ne comprend pas directement le format de sortie natif de PHPUnit : il attend des fichiers JSON structurés selon son propre schéma. Un adaptateur Composer se charge de cette conversion pendant l’exécution des tests :
composer require --dev allure-framework/allure-phpunit
# phpunit.xml.dist
<extensions>
<bootstrap class="Qameta\Allure\PHPUnit\AllureExtension"/>
</extensions>
Une fois cette extension déclarée, chaque exécution de phpunit génère un dossier build/allure-results contenant un fichier JSON par test exécuté, avec son statut, sa durée et, en cas d’échec, le message et la pile d’appels complète.
Générer le rapport HTML consultable
Le générateur Allure, distribué séparément en Java ou via un binaire autonome, lit ce dossier de résultats et produit un rapport HTML statique, consultable dans n’importe quel navigateur sans serveur applicatif dédié :
allure generate build/allure-results --clean -o build/allure-report
allure open build/allure-report
Le rapport obtenu classe les tests par suite, affiche un graphique de répartition des statuts (réussi, échoué, ignoré) et, pour chaque test en échec, présente la pile d’appels dans un panneau dédié plutôt que noyée dans un flux continu de texte.
Conserver l’historique pour voir la tendance
Le véritable intérêt d’Allure apparaît quand l’historique de plusieurs exécutions est conservé d’un build à l’autre. Sans cette précaution, chaque rapport repart de zéro et perd la vue sur la tendance (un test devenu instable, un temps d’exécution qui augmente progressivement).
- Copier le dossier
build/allure-report/historygénéré à l’exécution précédente dans le dossier de résultats avant la génération suivante. - Archiver ce dossier d’historique comme artefact persistant du pipeline d’intégration continue, entre deux exécutions.
- Vérifier dans le rapport l’onglet dédié aux tendances, qui affiche l’évolution du nombre de tests réussis sur les dernières exécutions.
Ce qu’un rapport visuel change en pratique pour une équipe
Un rapport texte brut demande une lecture linéaire et une certaine habitude pour repérer rapidement la cause d’un échec. Un rapport Allure permet à un membre de l’équipe non familier du projet de comprendre en un coup d’œil quel test a échoué et pourquoi, sans devoir demander d’explication au développeur qui a écrit le test :
- Filtrage par suite, par statut ou par étiquette personnalisée ajoutée dans le code du test.
- Regroupement automatique des échecs qui partagent le même message d’erreur, utile pour repérer une cause commune.
- Export du rapport en artefact de pipeline, consultable même après suppression de l’environnement d’exécution.
Un rapport que personne ne consulte n’a aucune valeur : publier le lien du rapport Allure directement dans la notification de build échoué change beaucoup plus le réflexe de l’équipe que le rapport lui-même.
Une limite à connaître avant de généraliser
Allure ajoute une étape de génération supplémentaire au pipeline, avec sa propre dépendance (le générateur Java ou son binaire). Sur un petit projet avec une suite de quelques dizaines de tests, la sortie texte de PHPUnit peut rester suffisante ; l’investissement se justifie surtout à partir du moment où plusieurs personnes doivent interpréter les résultats sans connaître le détail du code testé.
En résumé
Allure convertit les résultats bruts de PHPUnit en un rapport HTML navigable, avec historique des tendances, grâce à un adaptateur Composer dédié et à un générateur distinct exécuté après les tests. Le gain principal n’est pas technique mais humain : un échec devient compréhensible sans avoir à dérouler une sortie texte longue et rébarbative.
