# Tester une extension conforme à l’Abilities API avant WordPress 6.9

> WordPress 6.9 n'est pas encore sorti, mais l'Abilities API se teste dès maintenant contre les versions de développement du cœur. Voici comment structurer cette suite en avance de phase.

- Auteur : Clément Hadrot
- Publié le : 2025-10-03
- Mis à jour le : 2025-10-03
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tester-extension-abilities-api-avant-wp-6-9/

## L’essentiel

- Installer WordPress depuis la branche de développement, pas une version stable
- Isoler les tests spécifiques à l'Abilities API dans un groupe dédié
- Prévoir que l'API bouge encore d'ici la sortie finale

`wp core download --version=nightly` — c'est la commande qui ouvre ce chantier. WordPress 6.9 n'est pas encore sorti (sortie prévue en décembre 2025), mais l'Abilities API, qui permet à une extension de déclarer des capacités consommables par un système externe, est déjà stabilisée dans la branche de développement du cœur. Pour une extension qui veut être prête au lancement, attendre la version stable pour commencer à tester est une option, mais c'est aussi celle qui laisse le moins de marge de correction.

Ce billet documente comment nous avons construit une suite de tests contre une version de développement du cœur, avec les précautions que cela impose. Il ne traite pas du MCP Adapter, qui consomme les abilities déclarées mais reste un sujet distinct, postérieur dans notre feuille de route de tests.

## Installer une base de test sur une version de développement

La première difficulté est environnementale : une version nightly de WordPress change de contenu régulièrement, parfois plusieurs fois par semaine pendant la phase de stabilisation. Notre configuration de CI fixe donc un instantané daté plutôt que de suivre `nightly` en continu, pour éviter qu'un changement du cœur ne casse la suite sans rapport avec notre code :

```
#!/usr/bin/env bash
WP_VERSION_TAG="6.9-beta2"
wp core download --version="$WP_VERSION_TAG" --force
wp core install --url=localhost --title=Test --admin_user=admin --admin_password=admin --admin_email=test@example.com
```

Le tag précis est mis à jour manuellement à chaque nouvelle bêta, avec un commentaire dans le fichier de configuration expliquant pourquoi cette version a été choisie plutôt qu'une autre.

## Déclarer une ability et vérifier son enregistrement

Une ability se déclare via la fonction `wp_register_ability()`, en indiquant un identifiant, un schéma d'entrée, un schéma de sortie et une fonction de rappel. Le premier niveau de test consiste simplement à vérifier que l'enregistrement a bien lieu et que le schéma déclaré est conforme à ce qui est attendu par le registre des abilities.

> L'essentiel à retenir : Installer WordPress depuis la branche de développement, pas une version stable ; Isoler les tests spécifiques à l'Abilities API dans un groupe dédié ; Prévoir que l'API bouge encore d'ici la sortie finale

## Tester le schéma d'entrée avec des données limites

L'intérêt principal de l'Abilities API est de définir un contrat strict via un schéma JSON. Nos tests couvrent systématiquement :

- Une entrée valide minimale (uniquement les champs requis)
- Une entrée avec un champ requis manquant, pour vérifier que l'ability refuse l'appel avec une erreur explicite
- Une entrée avec un type incorrect (chaîne au lieu d'entier), pour vérifier la validation de type
- Une entrée avec des champs supplémentaires non déclarés, selon que le schéma les tolère ou les rejette

### Un exemple concret

```
public function test_ability_rejette_entree_sans_champ_requis(): void
{
    $resultat = wp_execute_ability('mon-plugin/rechercher-produit', []);

    $this->assertWPError($resultat);
    $this->assertSame('missing_required_param', $resultat->get_error_code());
}
```

## Accepter que l'API bouge encore

Travailler contre une branche de développement signifie accepter que des signatures de fonctions changent avant la sortie finale. Nous avons dû adapter deux fois notre code d'enregistrement d'ability entre la bêta 1 et la bêta 2, une fois pour un renommage de paramètre, une autre pour un changement de structure du schéma de sortie. Un test qui échoue après une mise à jour du cœur nightly n'est pas nécessairement un bug de l'extension — c'est souvent un signal à remonter sur le canal de développement du cœur.

> Tester contre une bêta, c'est accepter que la moitié des échecs de CI viennent du cœur, pas de votre code — et documenter chaque cas pour ne pas le redécouvrir à la version suivante.

## En résumé

Attendre la sortie stable de WordPress 6.9 pour commencer à tester une extension conforme à l'Abilities API revient à découvrir les problèmes d'intégration au pire moment, celui du lancement. Une suite construite dès la phase bêta, avec une version figée et documentée, donne une marge de correction confortable. Référence utile : [make.wordpress.org](https://make.wordpress.org/core/) pour suivre l'avancement de l'API avant sa sortie officielle.