« Est-ce qu’on bascule sur Pest pour le prochain projet ? » La question revient régulièrement depuis que l’outil a gagné en popularité dans l’écosystème Laravel, avec sa syntaxe fonctionnelle qui tranche nettement avec les classes verbeuses de PHPUnit. Sur un projet WordPress, la réponse est moins évidente que sur un projet Laravel pur, pour une raison simple : toute la suite de tests officielle de WordPress, avec WP_UnitTestCase et son bootstrap, a été conçue autour de PHPUnit, pas autour de Pest.
On a testé les deux approches sur deux extensions comparables en complexité, l’une avec une suite PHPUnit classique, l’autre migrée vers Pest, pour comparer honnêtement l’expérience réelle plutôt que le discours marketing autour de chaque outil.
Ce que Pest change concrètement
Pest n’est pas un framework de tests concurrent de PHPUnit : c’est une couche de syntaxe qui s’exécute par-dessus PHPUnit, avec ses propres fonctions globales (test(), it(), expect()) qui masquent l’écriture de classes. Le même test s’écrit ainsi de façon nettement plus compacte :
// PHPUnit classique
class CalculTarifTest extends TestCase {
public function test_applique_la_remise_fidelite() {
$tarif = new CalculTarif( 100, 0.10 );
$this->assertEquals( 90.0, $tarif->total() );
}
}
// Équivalent en Pest
it('applique la remise fidélité', function () {
$tarif = new CalculTarif(100, 0.10);
expect($tarif->total())->toBe(90.0);
});Le gain de lisibilité est net sur des tests simples et nombreux, en particulier pour une équipe qui découvre les tests unitaires et trouve la syntaxe orientée classe de PHPUnit intimidante au premier abord.
Le point de friction : WP_UnitTestCase
La suite de tests officielle de WordPress fournit une classe WP_UnitTestCase, héritée de PHPUnit\Framework\TestCase, qui gère automatiquement l’installation d’une base de données de test, la création de contenus via des factories (WP_UnitTest_Factory), et la restauration de l’état entre chaque test. Une bonne partie des tests utiles sur une extension WordPress, tout ce qui touche aux hooks, aux CPT, aux requêtes, dépend directement de cette classe.
Pest sait fonctionner avec une classe de base personnalisée, via la fonction uses() placée en tête de fichier de test ou dans un fichier Pest.php de configuration :
// tests/Pest.php
uses(WP_UnitTestCase::class)->in('Feature');
Cette configuration fonctionne, mais elle demande de bien comprendre comment Pest résout le contexte $this à l’intérieur des closures de test, une source de confusion réelle pour une équipe qui n’a jamais manipulé cette mécanique auparavant.
Comparatif sur les critères qui comptent en pratique
| Critère | PHPUnit classique | Pest |
|---|---|---|
| Compatibilité WP_UnitTestCase | Native, sans configuration | Fonctionne, via uses() |
| Lisibilité des tests simples | Verbeuse | Compacte |
| Courbe d’apprentissage équipe | Connue de la majorité des développeurs PHP | À acquérir, syntaxe fonctionnelle |
| Documentation WordPress disponible | Abondante | Rare, à adapter soi-même |
| Plugins d’assertions (snapshots, architecture) | Via bibliothèques externes | Intégrés nativement |
| Performance d’exécution | Identique (même moteur) | Identique (même moteur) |
Le point de performance mérite d’être souligné : puisque Pest s’exécute au-dessus de PHPUnit, il n’y a strictement aucune différence de vitesse d’exécution entre les deux approches sur un même jeu de tests. La différence se joue uniquement sur l’expérience d’écriture, pas sur le temps de CI.
Les tests d’architecture, un vrai atout de Pest
Un apport spécifique de Pest, sans équivalent natif direct dans PHPUnit, est son mécanisme de tests d’architecture, qui permet de vérifier des règles structurelles sur le code, indépendamment de son comportement fonctionnel :
arch('les contrôleurs REST n'appellent jamais $wpdb directement')
->expect('MonExtension\\Rest')
->not->toUse('wpdb');
Ce type de test, qui bloque une régression d’architecture avant même qu’elle ne produise un bug fonctionnel, n’a pas d’équivalent aussi accessible côté PHPUnit sans bibliothèque tierce dédiée comme deptrac.
Migrer une suite existante : un chantier à ne pas sous-estimer
Convertir une suite PHPUnit existante et volumineuse vers Pest n’est pas une opération neutre. Les assertions se réécrivent presque mécaniquement, mais les data providers, les mocks complexes et les classes de tests abstraites partagées entre plusieurs suites demandent une adaptation manuelle cas par cas. Sur l’extension migrée pour ce comparatif, environ 200 tests, la conversion complète a représenté près de deux jours de travail, essentiellement passés sur les fixtures et les mocks les plus élaborés.
Changer d’outil de tests ne doit jamais se faire pour la syntaxe seule : le vrai gain se mesure à la vitesse à laquelle l’équipe entière, pas seulement son auteur, comprend et maintient la suite ensuite.
Notre verdict
Pour un nouveau projet, sans historique de tests à migrer, et une équipe ouverte à une syntaxe différente, Pest apporte une lisibilité réelle et des tests d’architecture utiles, sans coût de performance. Pour un projet existant avec une suite PHPUnit déjà volumineuse et fonctionnelle, ou une équipe qui alterne régulièrement entre plusieurs projets WordPress avec des conventions PHPUnit bien ancrées, la migration n’apporte pas un bénéfice suffisant pour justifier le chantier et le risque de confusion pendant la période de transition. Les deux outils testent exactement la même chose, avec la même fiabilité : le choix est une question d’ergonomie d’équipe, pas de capacité technique.
