Sur un projet de synchronisation avec un service de facturation externe, l’équipe devait tester une classe qui appelait une passerelle de paiement à travers une interface PasserellePaiement. Le débat en revue de code n’a duré que quelques minutes avant de tourner en rond : fallait-il utiliser createMock(), natif à PHPUnit, ou installer Mockery en plus ? La réponse la plus honnête est que les deux savent faire le travail de base, mais divergent nettement dès que les attentes deviennent plus fines.
Les deux outils permettent de créer un double de test respectant une interface, sans dépendre de l’implémentation réelle. La différence se joue sur l’expressivité de la syntaxe et sur la gestion des cas avancés, comme les arguments partiels ou les séquences d’appels.
Un mock simple avec PHPUnit natif
public function test_notifie_le_client_apres_paiement_reussi() {
$passerelle = $this->createMock( PasserellePaiement::class );
$passerelle->method( 'debiter' )
->willReturn( true );
$service = new Service_Commande( $passerelle );
$resultat = $service->valider( 4200 );
$this->assertTrue( $resultat );
}
Pour ce cas simple, createMock() suffit largement : pas de dépendance supplémentaire, syntaxe intégrée à PHPUnit, et une lisibilité correcte pour qui connaît déjà le framework.
Le même test avec Mockery
public function test_notifie_le_client_apres_paiement_reussi() {
$passerelle = Mockery::mock( PasserellePaiement::class );
$passerelle->shouldReceive( 'debiter' )
->once()
->with( 4200 )
->andReturn( true );
$service = new Service_Commande( $passerelle );
$resultat = $service->valider( 4200 );
$this->assertTrue( $resultat );
}
La syntaxe fluide de Mockery (shouldReceive, once, with, andReturn) se lit presque comme une phrase, et exprime en une ligne une attente précise sur le nombre d’appels et l’argument exact reçu — quelque chose de plus verbeux à écrire avec les outils natifs de PHPUnit.
Où Mockery prend l’avantage
| Besoin | PHPUnit natif | Mockery |
|---|---|---|
| Mock simple d’une interface | Suffisant | Suffisant, plus verbeux |
| Vérifier l’ordre exact des appels | Complexe (callbacks manuels) | ordered() natif |
| Correspondance partielle d’arguments | Callback de comparaison à écrire | Mockery::on() intégré |
| Mocker une classe finale ou statique | Non supporté nativement | Non supporté non plus, sans extension |
Où PHPUnit natif reste préférable
Pour une équipe qui découvre les tests, ajouter Mockery en plus de PHPUnit ajoute une syntaxe supplémentaire à apprendre, une dépendance Composer de plus, et un risque de confusion entre willReturn et andReturn selon l’outil utilisé dans tel ou tel fichier. Sur un projet WordPress de taille modeste, avec peu d’interfaces à mocker, les doubles natifs de PHPUnit couvrent largement les besoins sans complexité supplémentaire.
Les deux cohabitent sans problème
Sur nos projets plus anciens, on retrouve encore des mocks PHPUnit natifs sur les interfaces simples, et Mockery réservé aux scénarios où l’ordre des appels ou la correspondance d’arguments complexe justifie sa verbosité. Rien n’oblige à choisir un camp pour tout le projet.
En résumé
Le choix entre Mockery et les mocks natifs de PHPUnit dépend de la complexité des attentes à exprimer, pas d’une préférence de principe. Ces deux outils mockent des interfaces et des classes concrètes définies par votre propre code — simuler des fonctions globales de WordPress comme get_option() sans charger le cœur est un besoin différent, qui relève d’une bibliothèque à part.
