WordPress 7.0 : les changements de fixtures de test à anticiper

Chaque montée de version majeure de WordPress s’accompagne, côté suite de tests fournie par le cœur, d’ajustements aux classes utilisées par des milliers de plugins et thèmes pour leurs propres tests : WP_UnitTestCase, les classes de factory (WP_UnitTest_Factory_For_Post, WP_UnitTest_Factory_For_User, etc.) et les fixtures de données par défaut. Sur notre parc de projets d’agence, chaque montée de version majeure est précédée d’un audit ciblé de ces classes, avant même de nous soucier des nouveautés fonctionnelles mises en avant dans les notes de version.

Ce qui reste stable avec WordPress 7.0

Les classes de factory historiques (self::factory()->post, self::factory()->user, self::factory()->term) conservent leur signature et leur comportement général, ce qui garantit que la grande majorité des suites de tests existantes continuent de s’exécuter sans modification. C’est un point de continuité important à vérifier en premier, avant de chercher les changements plus subtils.

Ce qui change : les fixtures liées aux abilities

Avec l’introduction de l’Abilities API en WordPress 6.9, la suite de tests du cœur a introduit une nouvelle classe de factory, WP_UnitTest_Factory_For_Ability, permettant d’enregistrer rapidement une ability de test sans reproduire tout le mécanisme d’enregistrement manuel. WordPress 7.0 étend cette fixture avec des helpers supplémentaires pour simuler un appelant externe :

public function test_ability_refuse_appelant_sans_capacite() {
    $ability = self::factory()->ability->create( [
        'name'                => 'mon-plugin/test-fixture',
        'permission_callback' => fn() => current_user_can( 'manage_options' ),
    ] );

    $appelant = self::factory()->user->create( [ 'role' => 'subscriber' ] );
    wp_set_current_user( $appelant );

    $resultat = $ability->execute( [] );
    $this->assertWPError( $resultat );
}

Sur nos suites existantes qui enregistrent manuellement des abilities de test via wp_register_ability() directement dans setUp(), ce changement n’est pas bloquant, mais il justifie une simplification progressive vers la nouvelle factory, plus proche des conventions déjà connues pour les articles ou les utilisateurs.

Ce qui change : signature d’un helper de dates

Le helper interne utilisé par certains tests pour figer artificiellement l’heure courante change de signature dans la suite fournie par le cœur, au profit d’une API plus explicite compatible avec les évolutions internes de gestion du temps. Les suites qui appelaient directement l’ancien helper, plutôt que de passer par le filtre documenté pre_get_option ou l’utilitaire recommandé, doivent ajuster leur code d’assistance de test.

Checklist d’audit avant la montée de version

1. Exécuter la suite existante contre une version bêta de WordPress 7.0 dès sa disponibilité, dans un job CI séparé et non bloquant, pour observer les échecs sans impacter le pipeline principal.
2. Relever tout avertissement de dépréciation émis par les classes de test elles-mêmes, distinct des avertissements du code applicatif testé.
3. Vérifier que les fixtures personnalisées de l’agence, construites par-dessus les classes du cœur, n’étendent pas une méthode dont la signature interne a changé.
4. Mettre à jour phpunit-polyfills et la configuration de bootstrap des tests vers les versions compatibles annoncées pour 7.0, avant de traiter les échecs individuels.
5. Documenter dans le wiki interne de l’agence les ajustements effectués, pour que l’équipe projet suivante n’ait pas à refaire cet audit de zéro.

Ce que ce billet ne couvre pas

Les changements annoncés pour l’API REST avec WordPress 7.0 relèvent d’un chantier distinct, propre aux architectures headless, qui mérite son propre audit indépendant de celui des fixtures de test. Ce billet se concentre uniquement sur l’infrastructure de test elle-même, pas sur les fonctionnalités exposées aux consommateurs de l’API.

Pour aller plus loin

Une montée de version majeure de WordPress est souvent perçue par les équipes comme un chantier fonctionnel avant tout, ce qui relègue l’audit des fixtures de test à un second plan traité dans l’urgence. Sur nos projets, inverser cet ordre — auditer d’abord l’infrastructure de test, ensuite les fonctionnalités — a systématiquement réduit le temps total de migration, puisque une suite de tests fiable dès le départ accélère ensuite la validation de tout le reste.