$this->assertQueryTrue( 'is_single', 'is_singular' ); : cette ligne, propre à la suite de tests intégrée à WordPress, vérifie quelque chose qu’un simple code de statut HTTP ne peut jamais garantir. Un serveur peut parfaitement répondre 200 tout en affichant une page d’archive à la place d’un article individuel, ou une page 404 mal configurée qui renvoie malgré tout un contenu.
Pour les développeurs qui testent le routage de contenu de WordPress plutôt que le seul comportement HTTP superficiel, cette méthode d’assertion comble un manque réel : elle interroge directement les conditions de requête internes de WordPress, les mêmes que celles utilisées dans les thèmes pour décider quel gabarit charger.
Étape 1 : comprendre ce que vérifie is_single, is_page et consorts
WordPress expose une série de fonctions conditionnelles, is_single(), is_page(), is_archive(), is_search(), is_404(), qui reflètent l’analyse de la requête courante par l’objet global WP_Query. Un thème s’appuie sur ces fonctions dans sa hiérarchie de gabarits pour choisir quel fichier PHP afficher. Tester qu’un gabarit charge le bon contenu revient donc, en réalité, à tester que la bonne combinaison de ces fonctions retourne true, et que toutes les autres retournent false.
Étape 2 : simuler une requête avec go_to
public function test_page_article_charge_le_bon_contexte(): void {
$post_id = self::factory()->post->create( [ 'post_type' => 'post' ] );
$this->go_to( get_permalink( $post_id ) );
$this->assertQueryTrue( 'is_single', 'is_singular' );
}
La méthode go_to, fournie par WP_UnitTestCase, simule une navigation complète vers l’URL indiquée : elle réinitialise l’objet WP_Query global et relance l’analyse de requête exactement comme le ferait une vraie visite. C’est cette étape qui rend possible la vérification suivante, puisque sans elle, aucune condition de requête ne serait réellement définie.
Étape 3 : appeler assertQueryTrue avec toutes les conditions attendues
Le point le plus important à comprendre concerne la liste complète des arguments à fournir. assertQueryTrue ne vérifie pas seulement que les conditions passées en argument sont vraies : elle vérifie aussi que toutes les autres conditions possibles, non listées, sont fausses. Un appel incomplet fait donc échouer le test, même si la condition attendue est bien active :
public function test_erreur_frequente_liste_incomplete(): void {
$post_id = self::factory()->post->create( [ 'post_type' => 'post' ] );
$this->go_to( get_permalink( $post_id ) );
// Échoue : is_singular est également vraie sur un article individuel
// et n'a pas été listée ici.
$this->assertQueryTrue( 'is_single' );
}
La correction consiste à lister systématiquement toutes les conditions vraies pour ce contexte précis, ce qui oblige, en creux, à bien connaître la hiérarchie des conditions de WordPress : un article individuel est à la fois is_single et is_singular, une page statique est is_page et is_singular, une archive de catégorie est is_archive et is_category.
Étape 4 : tester un contexte d’archive
public function test_archive_categorie_charge_le_bon_contexte(): void {
$categorie_id = self::factory()->category->create( [ 'name' => 'Actualités' ] );
self::factory()->post->create( [ 'post_category' => [ $categorie_id ] ] );
$this->go_to( get_category_link( $categorie_id ) );
$this->assertQueryTrue( 'is_archive', 'is_category' );
}
Ce test confirme que naviguer vers l’URL d’une catégorie déclenche bien les deux conditions attendues, ni plus ni moins. Si une extension du projet ajoute par erreur un filtre qui modifie la requête principale et fait basculer cette page en is_search, ce test échoue immédiatement, alors qu’un simple contrôle du code HTTP n’aurait rien détecté puisque la page continuerait de répondre normalement.
Étape 5 : documenter le contexte attendu directement dans le test
Un test qui utilise assertQueryTrue avec une liste explicite et complète de conditions sert aussi de documentation vivante du comportement attendu du routage. En cas de doute ultérieur sur le fonctionnement de la hiérarchie de gabarits d’un thème personnalisé, ce test répond directement à la question, sans avoir à consulter la documentation officielle du cœur ni à relire le code du thème lui-même.
Un code HTTP 200 confirme qu’une réponse a été envoyée ; seule une vérification du contexte de requête confirme que c’est la bonne réponse qui a été envoyée.
Étape 6 : combiner avec une vérification du contenu affiché
public function test_archive_categorie_affiche_larticle(): void {
$categorie_id = self::factory()->category->create();
$post_id = self::factory()->post->create( [ 'post_category' => [ $categorie_id ] ] );
$this->go_to( get_category_link( $categorie_id ) );
$this->assertQueryTrue( 'is_archive', 'is_category' );
global $wp_query;
$this->assertContains( $post_id, wp_list_pluck( $wp_query->posts, 'ID' ) );
}
Cette dernière étape combine la vérification du contexte de requête et celle du contenu réellement retourné par la boucle principale, ce qui couvre à la fois le routage et les données affichées.
En résumé
assertQueryTrue vérifie une dimension du comportement de WordPress que le seul code HTTP ne peut jamais capturer : le contexte de requête interne qui détermine quel gabarit et quel contenu s’affichent réellement. Utilisée avec une liste complète et explicite des conditions attendues, elle rend un test de routage à la fois rigoureux et directement lisible comme documentation du comportement voulu.
