Chaque sortie majeure de WordPress s’accompagne, pour l’équipe qui maintient des extensions, d’un même rituel : lire attentivement le journal des modifications de la suite de tests officielle avant de lire celui des nouveautés fonctionnelles elles-mêmes. Avec la sortie de la version 7.0, ce rituel a valu le détour : plusieurs évolutions touchent directement la façon dont les extensions tierces doivent adapter leurs propres suites PHPUnit et E2E pour rester alignées avec le cœur.
Cet article se concentre exclusivement sur ces évolutions d’outillage de tests, pas sur les nouveautés fonctionnelles de la version elle-même, qui font l’objet d’articles séparés sur ce blog.
Détection automatique du pilote de base de données dans le bootstrap
Le bootstrap fourni par la suite de tests officielle détecte désormais automatiquement si l’environnement d’exécution utilise MySQL ou SQLite, sans qu’il soit nécessaire de définir manuellement une constante ou une variable d’environnement dédiée comme c’était le cas auparavant sur les installations utilisant l’intégration SQLite. Pour une extension qui fait déjà tourner sa suite sur les deux moteurs en parallèle, cela simplifie la configuration du bootstrap :
// Avant WordPress 7.0 : configuration explicite nécessaire
define( 'WP_TESTS_USE_SQLITE', true );
require $_tests_dir . '/includes/bootstrap.php';
// À partir de WordPress 7.0 : détection automatique
require $_tests_dir . '/includes/bootstrap.php';Attention toutefois : les extensions qui exécutaient des requêtes SQL brutes spécifiques à un moteur, en dehors de $wpdb, doivent vérifier explicitement quel moteur est actif au moment du test, la détection automatique ne dispensant pas d’adapter le code si celui-ci reste couplé à la syntaxe MySQL.
Factories enrichies pour les types de contenu récents
Les factories de test (WP_UnitTest_Factory) gagnent des méthodes dédiées pour créer plus simplement des contenus liés aux fonctionnalités introduites lors des versions précédentes, notamment pour les abilities enregistrées et pour certains gabarits liés à l’éditeur de site. Une extension qui, jusque-là, construisait manuellement ces objets de test via des appels multiples peut désormais s’appuyer sur ces raccourcis :
// Avant : construction manuelle en plusieurs étapes
$post_id = self::factory()->post->create( [ 'post_type' => 'wp_template' ] );
// ... configuration manuelle supplémentaire du contenu de bloc
// À partir de WordPress 7.0
$template_id = self::factory()->template->create( [
'slug' => 'gabarit-test',
'content' => '<!-- wp:paragraph --><p>Contenu de test</p><!-- /wp:paragraph -->',
] );Ce raccourci ne change rien de fondamental dans ce qui est réellement testé, mais réduit la quantité de code de préparation dans chaque test, un gain de lisibilité qui compte sur une suite volumineuse où ces constructions reviennent des dizaines de fois.
Fin de la migration des scénarios E2E historiques vers le harnais moderne
Le dépôt officiel de WordPress maintient depuis plusieurs années deux générations de tests E2E en parallèle : d’anciens scénarios hérités de l’époque Puppeteer, progressivement portés vers le harnais moderne basé sur Playwright, et les nouveaux scénarios écrits directement dans ce cadre récent. Avec la version 7.0, cette migration atteint son terme : l’ensemble des scénarios E2E de référence du cœur tourne désormais exclusivement sur Playwright, et les utilitaires de test hérités de l’ancienne génération sont retirés du dépôt.
Pour une extension qui réutilisait certains de ces utilitaires historiques dans ses propres tests E2E, souvent pour simuler la connexion à l’administration ou naviguer dans l’éditeur de blocs, cette suppression implique de basculer vers les utilitaires équivalents du paquet @wordpress/e2e-test-utils-playwright, déjà stabilisé depuis plusieurs versions précédentes.
// Utilitaire hérité, retiré du dépôt en 7.0
import { visitAdminPage } from '@wordpress/e2e-test-utils';
// Équivalent stable à utiliser désormais
import { Admin } from '@wordpress/e2e-test-utils-playwright';
const admin = new Admin( { page, pageUtils, requestUtils } );
await admin.visitAdminPage( 'edit.php' );Ce que cela implique concrètement pour une extension tierce
- Vérifier dans son propre
composer.jsonetpackage.jsonqu’aucune dépendance ne pointe encore vers les utilitaires E2E hérités désormais retirés du cœur - Retester la matrice de compatibilité PHP et base de données avec la nouvelle détection automatique du bootstrap, en particulier si la configuration précédente forçait explicitement un moteur
- Profiter des nouvelles méthodes de factories pour simplifier les tests existants portant sur des gabarits ou des abilities, sans urgence particulière puisque l’ancienne construction manuelle continue de fonctionner
Rejouer la suite complète avant toute publication liée à la 7.0
Comme pour chaque montée de version majeure du cœur, la recommandation reste la même : ne pas se fier uniquement à la lecture du journal des modifications, mais rejouer effectivement l’intégralité de la suite de tests, unitaire, intégration et E2E, contre une installation WordPress 7.0 fraîchement provisionnée, avant de déclarer une extension compatible avec cette nouvelle version dans son en-tête.
Un journal des modifications, aussi bien rédigé soit-il, décrit ce que les mainteneurs du cœur ont pensé à documenter. Seule l’exécution réelle de votre propre suite de tests révèle ce qu’ils n’ont pas anticipé pour votre cas d’usage précis.
Pour aller plus loin
Ces évolutions d’outillage, moins visibles que les nouveautés fonctionnelles d’une version majeure, méritent pourtant d’être suivies avec la même rigueur : elles déterminent directement combien de temps une équipe passera à adapter ses propres tests avant de pouvoir déclarer sereinement sa compatibilité avec la nouvelle version. Sur les projets qu’on maintient, cette veille dédiée à l’outillage de tests, distincte de la veille fonctionnelle habituelle, a plusieurs fois permis d’anticiper une adaptation avant même la sortie stable de la version concernée, en travaillant directement sur les versions bêta du cœur.
