# assertQueryTrue() vérifie qu’une page charge le bon contexte de requête

> Un code HTTP 200 ne dit rien du contexte réel affiché. Une méthode dédiée de la suite de tests WordPress vérifie que la bonne condition de requête est active.

- Auteur : WordPress Développement
- Publié le : 2022-01-23
- Mis à jour le : 2022-01-23
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/assertquerytrue-verifie-contexte-requete/

## L’essentiel

- Vérifie la condition de requête active, pas seulement le code HTTP
- Détecte un contenu affiché dans le mauvais contexte
- S'utilise avec les fonctions is_ ciblées

`$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

> L'essentiel à retenir : Vérifie la condition de requête active, pas seulement le code HTTP ; Détecte un contenu affiché dans le mauvais contexte ; S'utilise avec les fonctions is_ ciblées

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.