vendor/bin/phpunit --group extension-facturation — cette seule ligne suffit à limiter l’exécution à un sous-ensemble de tests, à condition que les classes ou méthodes concernées portent l’annotation correspondante. Pas de fichier de configuration additionnel, pas de dossier séparé : juste une étiquette posée directement dans le code.
Pour une agence qui maintient dans un même dépôt les tests de plusieurs extensions WordPress, ou pour un mono-dépôt qui regroupe plusieurs modules applicatifs, cette annotation évite d’avoir à lancer l’intégralité d’une suite volumineuse pour vérifier un seul périmètre. Ce sujet ne traite pas des attributs PHP 8 introduits plus tard par PHPUnit : il reste ici sur l’annotation docblock @group, encore largement utilisée dans les projets qui n’ont pas migré leur syntaxe.
Poser l’annotation
L’annotation se place dans le docblock, au niveau de la classe pour l’appliquer à toutes ses méthodes, ou au niveau d’une méthode précise pour un ciblage plus fin :
/**
* @group extension-facturation
*/
class FacturationTest extends WP_UnitTestCase
{
public function test_le_montant_ttc_est_calcule(): void
{
$this->assertSame(120.0, calculerTTC(100.0, 0.2));
}
/**
* @group extension-facturation
* @group lent
*/
public function test_genere_le_pdf_complet(): void
{
$chemin = genererFacturePdf(42);
$this->assertFileExists($chemin);
}
}
La seconde méthode illustre un usage fréquent : cumuler deux groupes sur une même méthode, ici pour signaler à la fois son appartenance à l’extension de facturation et sa lenteur relative, ce qui permet de l’exclure séparément d’une exécution rapide.
Filtrer l’exécution en ligne de commande
Une fois les groupes posés, plusieurs options de la CLI PHPUnit permettent de composer des exécutions ciblées :
--group extension-facturationn’exécute que les tests portant ce groupe.--exclude-group lentretire les tests marqués comme lents, quelle que soit l’extension.- Les deux options se combinent :
--group extension-facturation --exclude-group lentne lance que les tests rapides de cette extension précise.
Où placer cette logique dans un projet multi-extensions
Dans un dépôt qui héberge les tests de plusieurs extensions maintenues par la même équipe, une convention de nommage simple évite les collisions : préfixer chaque groupe par le nom de l’extension (extension-facturation, extension-newsletter) plutôt que d’utiliser un nom générique comme integration qui finirait par regrouper des tests sans rapport les uns avec les autres.
Cette convention permet aussi de composer un script de développement local qui ne lance que l’extension sur laquelle une personne travaille, sans attendre l’exécution complète du reste du dépôt :
#!/usr/bin/env bash
set -euo pipefail
EXTENSION="${1:?Usage: ./test-extension.sh nom-extension}"
vendor/bin/phpunit --group "extension-${EXTENSION}"
Une limite à connaître : le groupe n’est pas un filtre de fichier
L’annotation @group ne dispense pas d’autoloader correctement chargé pour l’ensemble des classes de test : PHPUnit continue de découvrir tous les fichiers déclarés dans phpunit.xml, puis filtre a posteriori en fonction des groupes demandés. Sur une suite volumineuse, cela signifie que le filtrage par groupe accélère l’exécution des tests eux-mêmes, mais pas nécessairement la phase de découverte des fichiers, qui reste proportionnelle à la taille totale de la suite.
Le groupe spécial data et le nommage réservé
PHPUnit réserve quelques noms de groupes à un usage interne, notamment ceux générés automatiquement à partir du nom de la classe. Il vaut mieux réserver les noms de groupes personnalisés à des identifiants explicites (nom d’extension, niveau de rapidité, type de test) plutôt que des mots courts susceptibles d’entrer en collision avec une convention future de l’équipe.
En résumé
L’annotation @group offre un filtrage économique en configuration pour cibler l’exécution des tests d’une extension précise dans une suite partagée. Une convention de nommage cohérente, préfixée par le nom de l’extension, transforme cette simple étiquette en un outil de découpage fiable, sans avoir à multiplier les fichiers phpunit.xml ni à réorganiser l’arborescence des tests.
