# wp_cache_flush_runtime plutôt que tout vider entre deux requêtes de test

> Des tests automatisés qui purgent tout le cache d'objets entre chaque scénario perdent un temps précieux. Un correctif simple avec wp_cache_flush_runtime, réservé au cache mémoire de la requête.

- Auteur : Clément Hadrot
- Publié le : 2025-07-11
- Mis à jour le : 2025-07-11
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/wp-cache-flush-runtime-tests-automatises-cache-objets/

## L’essentiel

- wp_cache_flush appliquée entre chaque test vide aussi le cache persistant partagé
- wp_cache_flush_runtime ne vide que le cache mémoire local à la requête en cours
- Le gain de temps se compte en minutes sur une suite de tests complète

`wp_cache_flush();` — cette seule ligne, placée dans la fonction de préparation d'une suite de tests automatisés, s'est révélée responsable d'un ralentissement inattendu constaté sur un projet utilisant PHPUnit avec l'environnement `wp-env`.

## Le problème : une purge trop large entre chaque scénario

La suite de tests en question exécutait plus de trois cents scénarios, chacun précédé d'un appel à `wp_cache_flush()` pour repartir d'un état de cache propre. Ce réflexe, hérité d'un ancien projet, avait du sens tant que le site tournait avec le cache non persistant par défaut de WordPress.

Le problème est apparu une fois un objet cache persistant (Redis) installé sur l'environnement de test pour se rapprocher des conditions de production : `wp_cache_flush()` vide alors indistinctement le cache mémoire de la requête en cours et le cache persistant partagé, ce qui force Redis à reconstruire l'intégralité de ses entrées à chaque nouveau scénario, y compris celles qui n'ont aucun rapport avec le test en cours.

## Le correctif : ne vider que ce qui doit l'être

WordPress propose depuis la version 6.0 une fonction plus ciblée, `wp_cache_flush_runtime()`, qui ne vide que le cache non persistant de la requête PHP en cours, sans toucher au cache persistant partagé par ailleurs. C'est exactement le comportement souhaité entre deux scénarios de test qui n'ont pas besoin de repartir d'un cache Redis vide, mais seulement d'un état de requête neuf.

> L'essentiel à retenir : wp_cache_flush appliquée entre chaque test vide aussi le cache persistant partagé ; wp_cache_flush_runtime ne vide que le cache mémoire local à la requête en cours ; Le gain de temps se compte en minutes sur une suite de tests complète

```
// Avant : purge complète, coûteuse sur un objet cache persistant
public function setUp(): void {
    parent::setUp();
    wp_cache_flush();
}

// Après : purge limitée au cache de la requête en cours
public function setUp(): void {
    parent::setUp();
    wp_cache_flush_runtime();
}
```

Le gain constaté sur l'ensemble de la suite de tests, exécutée en intégration continue, s'est élevé à plus de quatre minutes sur un total d'environ dix-huit minutes, un allègement suffisant pour justifier la vérification de chaque suite de tests existante utilisant un objet cache persistant.

## Variantes selon le type de test

Ce remplacement ne convient pas à tous les scénarios. Trois cas de figure méritent d'être distingués :

- Un test qui vérifie uniquement un comportement métier isolé, sans dépendre du contenu du cache persistant : `wp_cache_flush_runtime()` suffit largement
- Un test qui vérifie explicitement le comportement du cache persistant lui-même, par exemple l'expiration d'une clé Redis : `wp_cache_flush()` reste nécessaire, au moins pour ce scénario précis
- Un test qui vérifie un groupe de cache non persistant particulier : la fonction `wp_cache_flush_group()`, plus récente, permet de cibler un seul groupe sans purger le reste

### Un point de vigilance sur la compatibilité

Certains plugins d'objet cache tiers n'implémentent pas encore intégralement `wp_cache_flush_runtime()` et se contentent d'un alias vers `wp_cache_flush()` classique. Il est donc utile de vérifier, avant de généraliser ce remplacement, que le plugin réellement utilisé en environnement de test respecte bien la distinction entre cache de requête et cache persistant.

> Purger tout par réflexe est souvent plus simple à écrire, rarement plus simple à faire tourner à l'échelle d'une suite de tests complète.

## En résumé

Un remplacement d'une ligne, mais un gain de temps loin d'être négligeable sur une suite de tests conséquente. Ce billet ne traite pas de la configuration de Redis en production, qui répond à des exigences différentes de celles d'un environnement de test automatisé.