[true, false, null, 'fr_FR', 3, false] : que représente chacune de ces six valeurs sans ouvrir la définition de la méthode testée ? C’est la question que pose tout data provider PHPUnit dont les cas de test s’accumulent avec le temps, chaque nouveau paramètre ajouté rendant la ligne précédente plus difficile à déchiffrer sans naviguer entre deux fichiers.
PHP 8.0 introduit les arguments nommés, qui permettent d’associer explicitement chaque valeur à son paramètre plutôt que de compter sur sa position dans la liste. Appliqués à un data provider fourni, ils transforment un tableau de valeurs opaques en une description directement lisible.
Le problème d’un data provider positionnel
public function fournisseur_configurations(): array {
return [
'utilisateur connecté, langue française' => [ true, false, null, 'fr_FR', 3, false ],
'invité, langue anglaise, cache actif' => [ false, true, null, 'en_US', 0, true ],
];
}
/**
* @dataProvider fournisseur_configurations
*/
public function test_rendu_page( $connecte, $cache, $utilisateur, $locale, $tentatives, $mode_debug ): void {
// ...
}
Le libellé du cas de test aide à comprendre l’intention générale, mais dès qu’il faut vérifier quelle valeur correspond à quel paramètre, la seule solution consiste à compter les virgules dans le tableau, puis à faire correspondre cette position avec la signature de la méthode testée, potentiellement dans un autre fichier ou plus bas dans le même fichier.
La méthode avec des arguments nommés
/**
* @dataProvider fournisseur_configurations
*/
public function test_rendu_page(
bool $connecte,
bool $cache,
?int $utilisateur,
string $locale,
int $tentatives,
bool $mode_debug
): void {
// ...
}
public function fournisseur_configurations(): array {
return [
'utilisateur connecté, langue française' => [
'connecte' => true,
'cache' => false,
'utilisateur' => null,
'locale' => 'fr_FR',
'tentatives' => 3,
'mode_debug' => false,
],
];
}
Techniquement, ce tableau associatif fonctionne déjà avec PHPUnit avant même l’existence des arguments nommés en PHP, du moment que les clés correspondent exactement au nom des paramètres attendus par la méthode de test. Ce que PHP 8.0 apporte en plus, c’est la possibilité de construire ces tableaux avec la même syntaxe explicite ailleurs dans le code, en particulier lors de l’appel direct d’une fonction utilitaire de préparation de fixture.
Là où le gain devient concret : construire la fixture elle-même
function construit_configuration(
bool $connecte = false,
bool $cache = false,
?int $utilisateur = null,
string $locale = 'fr_FR',
int $tentatives = 0,
bool $mode_debug = false
): array {
return compact( 'connecte', 'cache', 'utilisateur', 'locale', 'tentatives', 'mode_debug' );
}
$configuration = construit_configuration( locale: 'en_US', cache: true, tentatives: 5 );
Ici, seuls trois paramètres sur six sont précisés explicitement, dans un ordre qui ne correspond même pas à leur position dans la signature. Les autres conservent leur valeur par défaut. C’est cette combinaison, arguments nommés associée à des valeurs par défaut, qui rend un data provider particulièrement lisible : chaque cas de test ne montre que ce qui le distingue réellement du cas nominal, sans répéter les six paramètres à chaque fois.
Un jeu de données comparatif avant/après
| Approche | Lisibilité à la relecture | Risque d’inversion de paramètres |
|---|---|---|
| Tableau positionnel | Faible, dépend de la mémorisation de l’ordre | Élevé, surtout après ajout d’un paramètre |
| Tableau associatif avec clés | Bonne, chaque clé nomme sa valeur | Faible, une clé mal orthographiée est ignorée silencieusement par PHP en argument de tableau, à surveiller |
| Arguments nommés sur une fonction de fabrique | Très bonne, seuls les écarts au cas par défaut apparaissent | Faible, PHP lève une erreur sur un nom de paramètre inexistant |
Cette dernière ligne du tableau mérite d’être soulignée : contrairement à un tableau associatif classique, un argument nommé mal orthographié dans un appel de fonction provoque une erreur immédiate à l’exécution, plutôt qu’une valeur silencieusement absente.
Un data provider illisible n’est jamais un problème de PHPUnit, mais un problème de choix d’écriture : nommer explicitement chaque valeur coûte quelques caractères de plus et fait gagner des minutes de relecture à chaque nouvelle contribution.
Une limite à connaître
Les arguments nommés ne peuvent pas être utilisés dans la définition même de la structure d’un data provider fourni à l’annotation @dataProvider, qui reste un tableau indexé ou associatif classique. Le gain se situe dans les fonctions de fabrique appelées depuis ce data provider, pas dans le mécanisme d’annotation de PHPUnit lui-même.
En résumé
Les arguments nommés de PHP 8.0 ne changent rien au comportement d’un data provider, mais ils transforment la façon dont une équipe construit les fixtures qui l’alimentent. Combinés à des valeurs par défaut sensées, ils permettent à chaque cas de test de ne montrer que ce qui compte réellement, ce qui réduit directement le temps passé à relire un jeu de données à rallonge.
