PHPUnit est le framework de test PHP standard : basé sur des classes, conventions xUnit, partout. Pest est une couche au-dessus avec une syntaxe basée sur des fonctions, une API d'expectations, et des extras comme les tests d'architecture. Comme Pest utilise le moteur PHPUnit en dessous, le choix porte sur la façon d'écrire et d'organiser les tests, pas sur la capacité ou la vitesse. Laravel supporte les deux par défaut.

PHPUnit vs Pest en un coup d'oeil

PHPUnit : basé sur des classes et ubiquitaire

Un test PHPUnit est une classe qui étend le TestCase du framework, avec des méthodes nommées test* ou annotées comme tests. C'est verbeux, mais chaque développeur PHP et chaque système de CI le connaissent déjà, le support IDE est complet, et il y a une décennie d'exemples pour n'importe quel scénario. Pour une équipe qui vit dans PHPUnit, il n'y a aucune raison forcée de bouger.

Pest : des fonctions et des expectations

Pest remplace la classe par des fonctions it() et test() de haut niveau et les appels assert*() par une API chaînable expect(). Les datasets paramètrent un test sans méthode data provider, les expectations d'ordre supérieur se chaînent naturellement, et arch() vous laisse affirmer des règles sur votre propre code (pas de helpers de debug en production, les contrôleurs ne dépendent pas directement des modèles). Ça se lit bien et ça coupe le boilerplate.

Le même feature test Laravel, des deux façons

// PHPUnit
public function test_il_liste_les_commandes_de_l_utilisateur(): void
{
    $user = User::factory()->has(Order::factory()->count(2))->create();

    $this->actingAs($user)
        ->getJson('/api/v1/orders')
        ->assertOk()
        ->assertJsonCount(2, 'data');
}

// Pest
it('liste les commandes de l utilisateur', function () {
    $user = User::factory()->has(Order::factory()->count(2))->create();

    $this->actingAs($user)
        ->getJson('/api/v1/orders')
        ->assertOk()
        ->assertJsonCount(2, 'data');
});

Migrer PHPUnit vers Pest

Ils coexistent dans la même suite : Pest exécute vos classes PHPUnit existantes sans changement, donc vous pouvez l'adopter pour les nouveaux tests et convertir les anciens progressivement, ou pas du tout. Il y a aussi un outil de conversion qui réécrit les patterns courants. Aucune migration big-bang n'est requise.

Ce qui compte vraiment

Le framework est un petit facteur à côté du fait d'avoir des tests, de savoir s'ils couvrent les parties risquées, et s'ils tournent assez vite pour que les gens les lancent. Une app bien testée en PHPUnit bat une app peu testée en Pest à chaque fois. Prenez la syntaxe que votre équipe aimera écrire, parce que c'est ça qui pilote la couverture.

PHPUnit et Pest sont le même moteur avec une ergonomie différente. PHPUnit est le défaut sûr et universel ; Pest échange un peu de familiarité contre moins de boilerplate et les tests d'architecture. L'un ou l'autre convient. Ce qui compte, c'est que la suite existe, couvre le code risqué, et tourne assez vite pour que l'équipe continue de la lancer.