Une extension de recommandation de produits, construite pour s’enrichir des données fournies par une extension de fidélité tierce, peut se retrouver privée de cette dépendance en pleine exécution d’une requête, et non plus seulement absente au démarrage du site. La plupart des tests de compatibilité vérifient uniquement le second cas, plus simple à simuler : ils désactivent le plugin tiers avant de charger WordPress, puis vérifient que rien ne plante.
Ce scénario simplifié laisse échapper une catégorie d’incidents bien réelle : un administrateur qui désactive un plugin de fidélité pendant qu’une requête de recommandation est déjà en cours de traitement, ou un environnement où le plugin tiers échoue à charger correctement sans provoquer d’erreur fatale immédiate. Le test décrit ici cible précisément ce cas intermédiaire, plus difficile à reproduire qu’une simple absence au chargement.
Reproduire une désactivation en cours de requête
PHPUnit, combiné à l’environnement de test WordPress, permet de retirer artificiellement les fonctions d’un plugin tiers après le chargement complet de WordPress, en utilisant des doublures de fonctions plutôt qu’une réelle désactivation via la table d’options. Cette approche simule fidèlement un plugin dont le code reste chargé mais dont l’état interne devient incohérent, sans reproduire une simple absence de fichier.
public function ilContinueDeFonctionnerSiLeServiceDeFideliteDevientIndisponible(): void
{
// Le plugin tiers reste "présent" mais sa fonction principale
// est neutralisée en cours de requête, simulant une panne interne.
add_filter('fidelite_points_disponibles', function () {
throw new \RuntimeException('Service de fidélité indisponible');
}, 5);
$recommandation = $this->service_recommandation->construire_pour_client(42);
$this->assertNotEmpty($recommandation->produits());
$this->assertFalse($recommandation->utilise_points_fidelite());
}
Le code testé, côté extension
Le comportement attendu de l’extension repose sur une capture explicite de l’exception, plutôt que sur une simple vérification d’existence de fonction en amont, qui ne détecterait pas ce cas de panne en cours d’exécution :
public function construire_pour_client(int $id_client): Recommandation
{
try {
$points = apply_filters('fidelite_points_disponibles', 0, $id_client);
$utilise_fidelite = $points > 0;
} catch (\Throwable $e) {
$points = 0;
$utilise_fidelite = false;
$this->journal->avertir('Fidélité indisponible, recommandation en mode dégradé');
}
return new Recommandation(
$this->calculer_produits($id_client, $points),
$utilise_fidelite
);
}
Trois scénarios couverts, pas un seul
Le test présenté ci-dessus n’est qu’un des trois scénarios de la suite complète : le second simule une réponse du plugin tiers dans un format inattendu plutôt qu’une exception franche, et le troisième simule une lenteur excessive de sa fonction, pour vérifier qu’aucun délai d’exécution anormal ne se propage. Chacun vérifie une facette différente de la même exigence : aucune panne d’un plugin tiers ne doit provoquer d’erreur fatale sur la page visitée par un client.
Ce que ce type de test ne couvre pas
- Il ne remplace pas un test de compatibilité classique, qui vérifie l’absence de plugin tiers dès le chargement de WordPress.
- Il ne garantit rien sur la gestion des dépendances déclarées entre plugins, sujet distinct traité par le cœur de WordPress lui-même.
- Il exige une discipline de code : chaque appel à une fonctionnalité d’un plugin tiers doit être encadré par une gestion d’erreur explicite pour que ce type de test ait un sens.
Un plugin qui dépend d’un autre plugin doit se comporter comme si ce dernier pouvait disparaître à tout instant, pas seulement au démarrage.
En résumé
Simuler la défaillance d’un plugin tiers en cours de requête, plutôt que sa simple absence au chargement, révèle une catégorie de bugs de dégradation que les tests de compatibilité habituels laissent passer. Sur les trois scénarios couverts ici, aucune erreur fatale n’a été tolérée : chaque panne simulée doit se traduire par un mode dégradé explicite, journalisé et visible pour l’équipe de support, jamais par une page blanche pour le client.
