# Mockery ou les mocks natifs de PHPUnit pour tester WordPress ?

> Comparaison de la syntaxe, de la puissance et de l'intégration avec les tests WordPress, sur des exemples de code réels plutôt que sur des arguments théoriques.

- Auteur : Clément Hadrot
- Publié le : 2022-01-28
- Mis à jour le : 2022-01-28
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/mockery-ou-mocks-natifs-phpunit-wordpress/

## L’essentiel

- PHPUnit natif suffit pour la majorité des interfaces simples
- Mockery brille sur les attentes complexes et les arguments partiels
- Les deux cohabitent très bien dans un même projet

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 );
}
```

> L'essentiel à retenir : PHPUnit natif suffit pour la majorité des interfaces simples ; Mockery brille sur les attentes complexes et les arguments partiels ; Les deux cohabitent très bien dans un même projet

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.