Pest ou PHPUnit : migrer ses tests Laravel sans risque

Pest est devenu le choix par défaut de nombreux projets Laravel, mais PHPUnit n'a pas disparu : Pest est construit au-dessus de PHPUnit. La vraie question n'est donc pas « lequel garder », mais « faut-il changer la syntaxe de mes tests, et comment le faire sans risque ». Voici un comparatif honnête et une méthode de migration progressive.

Pest et PHPUnit : ce qui change vraiment

Les deux outils exécutent les mêmes tests avec le même moteur. La différence est d'abord une question d'écriture et d'ergonomie :

Syntaxe : Pest utilise des fonctions (test(), it()) et une API fluide (expect()), là où PHPUnit demande des classes et des méthodes assert*.
Lisibilité : les tests Pest sont plus courts et se lisent comme des phrases.
Fonctionnalités : tests de datasets, hooks simples, exécution en parallèle, architecture (tests d'architecture), couverture de code, et, depuis Pest 4, des tests de navigateur.
Compatibilité : les deux styles peuvent coexister dans le même projet, ce qui rend la migration progressive.

Voici un même test dans les deux syntaxes :

// PHPUnit
class ExampleTest extends TestCase
{
    public function test_that_true_is_true(): void
    {
        $this->assertTrue(true);
    }
}

// Pest
test('true is true', function () {
    expect(true)->toBeTrue();
});

Faut-il migrer ?

Oui, si votre équipe écrit beaucoup de tests, souhaite des tests plus lisibles, ou veut utiliser les fonctionnalités propres à Pest. Non, si la suite actuelle est stable, que personne ne la trouve pénible et que le temps est compté : réécrire des tests qui passent ne livre aucune valeur métier. Un bon compromis consiste à écrire les nouveaux tests en Pest et à convertir les anciens uniquement lorsqu'on les touche.

Étape 1 : installer Pest

Pest nécessite une version récente de PHP (consultez la documentation pour la version exacte selon la version de Pest). L'installation se fait avec Composer :

composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init
composer require pestphp/pest-plugin-laravel --dev

La commande --init crée le fichier tests/Pest.php, qui configure les classes de base utilisées par vos tests (par exemple pour associer le TestCase de Laravel aux dossiers Feature et Unit). Lancez ensuite la suite telle quelle : vos tests PHPUnit existants doivent continuer à passer.

./vendor/bin/pest

Étape 2 : convertir automatiquement avec Drift

Le plugin officiel Drift convertit les tests PHPUnit en tests Pest :

composer require pestphp/pest-plugin-drift --dev
./vendor/bin/pest --drift

Vous pouvez aussi limiter la conversion à un dossier :

./vendor/bin/pest --drift tests/Unit

La documentation indique que la plupart des tests se convertissent sans problème, mais que certains demandent une reprise manuelle (classes de base particulières, méthodes d'aide partagées, traits). Convertissez dossier par dossier et relancez la suite après chaque étape. Travaillez sur une branche dédiée et revoyez le diff : la conversion automatique n'est pas infaillible.

Étape 3 : tirer parti de Pest

Une fois la conversion faite, quelques fonctionnalités justifient le changement :

Datasets pour tester plusieurs cas avec un seul test :

it('rejects invalid emails', function (string $email) {
    expect(filter_var($email, FILTER_VALIDATE_EMAIL))->toBeFalse();
})->with(['foo', 'foo@', '@bar.com']);

Tests en parallèle : ./vendor/bin/pest --parallel réduit nettement le temps d'exécution sur les grosses suites.
Tests d'architecture pour imposer des règles (« aucun contrôleur n'utilise directement la façade DB »).
Tests de navigateur avec Pest 4, une alternative à un outil externe. Nous comparons les approches dans notre article Laravel : Playwright vs Pest et détaillons la mise en place dans le guide complet du testing Laravel avec Playwright.

Étape 4 : l'intégrer à votre chaîne de déploiement

Lancez pest dans votre intégration continue avant tout déploiement : un test qui ne tourne jamais automatiquement est vite abandonné. Notre guide sur le déploiement Laravel avec GitHub Actions montre où insérer cette étape. Les assistants de code gagnent aussi à s'appuyer sur une suite fiable : voir nos conseils sur Laravel Boost.

Pièges à éviter

convertir toute la suite d'un coup, sans filet ;
mélanger les deux styles sans règle d'équipe (choisissez : tout nouveau test en Pest) ;
oublier de mettre à jour la configuration CI et les scripts Composer ;
prendre la migration pour un objectif : le but reste d'avoir des tests utiles, pas des tests « jolis ».

Conclusion

Pest apporte une écriture plus claire et quelques outils en plus, sans rien retirer de PHPUnit. Une migration réussie est progressive : installation, vérification que tout passe, conversion par dossiers avec Drift, puis adoption des nouvelles fonctionnalités à votre rythme. Si votre suite actuelle vous convient, rien ne vous oblige à bouger — mais vos prochains tests peuvent déjà être écrits en Pest.