Un plugin de gestion de formulaires fonctionnait parfaitement en installation simple, mais une fois déployé sur un réseau multisite pour un groupe scolaire gérant douze sites, les soumissions d’un site se retrouvaient parfois enregistrées avec les métadonnées d’un autre. Le bug venait d’une requête SQL directe qui oubliait le préfixe de table propre à chaque site du réseau. Un test lancé en mode multisite l’aurait révélé avant la mise en production.
La suite de tests WordPress sait basculer en mode réseau sans changer une ligne de code de test : il suffit d’une constante dans wp-tests-config.php. Mais tous les tests n’ont pas vocation à tourner deux fois, et WordPress fournit un mécanisme de groupe pour cibler précisément ceux qui comptent en contexte réseau.
Activer le mode multisite dans la configuration de test
Dans wp-tests-config.php, une seule constante bascule l’ensemble de la suite en mode réseau :
define( 'WP_TESTS_MULTISITE', true );
Avec cette constante active, WP_UnitTestCase installe un réseau de test avec un site principal, et toutes les fonctions réseau (is_multisite(), get_sites(), switch_to_blog()) deviennent utilisables dans les tests comme en production. Sans elle, ces fonctions restent disponibles mais is_multisite() retourne systématiquement false, ce qui ne teste rien du comportement réseau réel.
Cibler les tests spécifiques au réseau avec @group ms-required
Certains tests n’ont de sens qu’en environnement multisite : ils échoueraient ou seraient ignorés à tort en installation simple. L’annotation @group ms-required permet de les filtrer explicitement :
/**
* @group ms-required
*/
class Test_Formulaires_Reseau extends WP_UnitTestCase {
public function test_isole_les_soumissions_par_site() {
$site_a = self::factory()->blog->create();
$site_b = self::factory()->blog->create();
switch_to_blog( $site_a );
$id_a = mon_plugin_enregistrer_soumission( array( 'email' => 'a@ecole.test' ) );
restore_current_blog();
switch_to_blog( $site_b );
$soumissions_b = mon_plugin_lister_soumissions();
restore_current_blog();
$this->assertEmpty( $soumissions_b );
}
}
À l’inverse, @group ms-excluded marque les tests qui doivent être ignorés en mode réseau, typiquement quand ils vérifient un comportement propre à une installation simple qui n’a pas d’équivalent en multisite.
Le piège de switch_to_blog
switch_to_blog() change le contexte de tables (options, posts, users spécifiques au site) mais ne recrée pas une connexion base séparée : c’est la même connexion MySQL, avec un préfixe de table différent. Deux erreurs reviennent souvent dans les tests multisite :
- Oublier
restore_current_blog()après chaqueswitch_to_blog(), ce qui laisse le contexte du site B actif pour les tests suivants - Utiliser
$wpdb->prefixen dur au lieu de laisser WordPress le résoudre dynamiquement, ce qui casse justement l’isolation entre sites que le multisite est censé garantir
Tester les capacités super-admin séparément
Le rôle administrator d’un site du réseau n’a pas les mêmes droits qu’un super-administrateur réseau. Un test qui vérifie l’accès à une fonctionnalité réseau doit explicitement élever l’utilisateur avec grant_super_admin(), sans quoi il valide un scénario qui ne reflète pas la réalité :
$user_id = self::factory()->user->create( array( 'role' => 'administrator' ) );
grant_super_admin( $user_id );
wp_set_current_user( $user_id );
En résumé
Le mode multisite de la suite de tests ne demande qu’une constante, mais encore faut-il cibler les bons tests avec les groupes appropriés et surveiller la restauration du contexte entre sites. La compatibilité multisite d’un plugin dans son ensemble — gestion des mises à jour réseau, activation forcée, réseau étendu — reste un chantier plus large que le seul cadrage de la suite de tests.
