wp_insert_term('Vélo', 'produit_categorie', ['parent' => $idCategorieSport]); — cette seule ligne construit un nœud enfant dans une arborescence de termes. La question qui se pose ensuite est presque toujours la même : combien de nœuds faut-il réellement créer pour qu’un test de get_terms() couvre les cas qui comptent, sans reconstituer toute la taxonomie d’un site réel ?
La réponse tient en une observation simple : la plupart des comportements intéressants de get_terms() sur une hiérarchie se manifestent dès trois niveaux de profondeur, avec deux ou trois termes par niveau. Au-delà, chaque nœud supplémentaire ajoute du temps d’exécution sans ajouter de nouveau cas à couvrir.
Ce qu’une taxonomie complète apporte en trop
Un jeu de fixtures qui reproduit fidèlement une taxonomie de production, avec ses dizaines de catégories et sous-catégories, teste implicitement les mêmes chemins de code plusieurs fois pour des données différentes. Le temps de création de ces termes en base de données, à travers wp_insert_term(), s’additionne à chaque exécution de la suite, sans qu’aucun de ces termes supplémentaires ne révèle un comportement que les premiers n’auraient pas déjà révélé.
Le minimum qui couvre les cas utiles
Une arborescence à trois niveaux, avec un embranchement à chaque niveau, suffit à exercer les paramètres les plus significatifs de get_terms() : filtrage par parent, récupération avec ou sans les enfants, tri hiérarchique.
class ArborescenceTermesFixture extends WP_UnitTestCase
{
private static int $racine;
private static int $enfantA;
private static int $petitEnfant;
public static function wpSetUpBeforeClass(WP_UnitTest_Factory $factory): void
{
register_taxonomy('produit_categorie', 'produit');
self::$racine = wp_insert_term('Sport', 'produit_categorie')['term_id'];
self::$enfantA = wp_insert_term('Vélo', 'produit_categorie', [
'parent' => self::$racine,
])['term_id'];
self::$petitEnfant = wp_insert_term('VTT', 'produit_categorie', [
'parent' => self::$enfantA,
])['term_id'];
}
public function test_get_terms_filtre_par_parent_direct(): void
{
$termes = get_terms([
'taxonomy' => 'produit_categorie',
'parent' => self::$racine,
'hide_empty' => false,
]);
$this->assertCount(1, $termes);
$this->assertSame(self::$enfantA, $termes[0]->term_id);
}
}
Les cas limites qui méritent un nœud dédié
- Un terme racine sans aucun enfant, pour vérifier que
get_terms()ne renvoie pas d’erreur ni de résultat inattendu sur une branche vide. - Deux termes frères au même niveau, pour vérifier que le tri par défaut (généralement alphabétique, sauf réglage explicite) reste stable et prévisible.
- Un terme sans article associé, pour vérifier le comportement de l’argument
hide_empty, qui exclut par défaut les termes sans contenu rattaché.
Ces trois cas se couvrent avec un ajout minimal à l’arborescence de base, sans avoir besoin de dupliquer toute la fixture pour chacun d’entre eux.
Un piège fréquent : oublier hide_empty
Par défaut, get_terms() applique l’argument hide_empty à true, ce qui exclut les termes sans article publié associé. Un test qui crée une arborescence de termes sans y rattacher au moins un article publié par terme obtient alors une liste vide, non pas parce que la logique testée est fautive, mais parce que la fixture ne satisfait pas ce filtre par défaut. Passer explicitement 'hide_empty' => false dans les arguments de test, ou associer un article à chaque terme testé, évite cette confusion fréquente chez qui découvre cette fonction.
En résumé
Construire une arborescence de termes minimale, à trois niveaux avec quelques embranchements ciblés, suffit à couvrir l’essentiel des comportements de get_terms() sur une hiérarchie. Reproduire une taxonomie complète de production en fixture n’ajoute aucune garantie supplémentaire, seulement du temps d’exécution ; réserver l’effort de fixture aux cas limites identifiés (branche vide, tri, articles associés) donne une suite à la fois rapide et représentative.
