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.
// 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é.
