PHP : dois-je me moquer ou dois-je y aller ?

Se moque en bref

Les simulations visent à tester le comportement d'objets réels.

Ils simulent des dépendances, vous n'avez donc pas besoin d'appeler des ressources externes qui pourraient ralentir considérablement les tests unitaires.

Vous pouvez définir des attentes et les vérifier.

Par exemple, vous pouvez vous assurer qu'une méthode est appelée un certain nombre de fois et/ou avec certains paramètres :

use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    public function testMockExample(): void
    {
        $depencencyMock = $this->createMock(MyDependency::class);

        $dependencyMock->expects($this->exactly(2))
              ->method('someMethod')
              ->with('some parameter');

        $classToTest = new ClassToTest($dependencyMock);
   }
}

Valeurs de retour

willReturn() assure la compatibilité avec les types de retour :

// In code
class MyClass {
    public function getNum(): int {
    }
}

// In tests
$myClassMock = $this->createMock(MyClass::class);
$myClassMock->expects($this->once())
            ->method('getNum')
            ->willReturn(2);

Vous pouvez également utiliser willReturnCallback si vous souhaitez tester le comportement dynamique en fonction des paramètres d'entrée.

Mauvaises pratiques à éviter

Comme les moqueries ne font qu'imiter des comportements réels, il est facile de passer à côté de l'essentiel. Discutons des mauvaises pratiques courantes :

Renvoyer des valeurs sans attentes

❌ Ne fais pas ça :

$colorServiceMock = $this->createMock(ColorService::class);
$colorServiceMock->method('hexToName')
     ->willReturn('red');

$color = (new MyClass($colorServiceMock))->getColorName('ff0000');

✅ Ajoutez plutôt quelques attentes :

$colorServiceMock->expects($this->once())
     ->method('hexToName')
     ->with('00f00')
     ->willReturn('green');

$color = (new MyClass($colorServiceMock))->getColorName('00f00');

Rappelez-vous que les simulations visent à vérifier les interactions.

Se moquer d'objets réels au lieu d'interfaces

Testons MyClass qui implémente SomeInterface.

❌ Ne fais pas ça :

$myclassMock = $this->createMock(MyClass::class);

✅ Au lieu de cela, moquez-vous de l'interface :

$myclassMock = $this->createMock(SomeInterface::class);

Les moqueries se concentrent sur les comportements. Les interfaces ne changent généralement pas, car vous êtes censé modifier les implémentations, pas les contrats.

Tests de surmocking

Tomas Votruba explique magnifiquement ce problème : 5 façons d'extraire de la valeur des tests sursimulés

Utiliser des simulations pour masquer les mauvaises pratiques de conception

Il est facile d'ignorer un couplage étroit entre les composants :

$productRepositoryMock = $this->createMock(ProductRepository::class);
$invoiceRepositoryMock = $this->createMock(InvoiceRepository::class);
$emailServiceMock = $this->createMock(EmailService::class);

$overComplexService = new OverComplexService($productRepositoryMock, $invoiceRepositoryMock, $emailServiceMock);

L'exemple ci-dessus brise la séparation des préoccupations, et les moqueries perpétuent cette mauvaise pratique.

S'appuyer exclusivement sur des simulations

Les simulations sont des outils puissants, mais les tests unitaires ne suffisent pas. Vous avez besoin de divers autres types de tests (par exemple, intégration, e2e).

Comment repérer une mauvaise utilisation des simulations

En plus des mauvaises pratiques, il existe d'autres signes qui pourraient indiquer que les simulations sont utilisées à mauvais escient ou surutilisées dans le projet :

• les tests ne reflètent pas les scénarios du monde réel, négligeant les problèmes critiques de la production
• il y a un couple serré entre tests et implémentations, ce qui entraîne des mises à jour fréquentes des mocks associés
• les tests sont trop complexes, ce qui les rend plus difficiles à lire et à maintenir

Mocks et talons

Martin Fowler a écrit un article fantastique qui explique pourquoi les moqueries ne sont pas des talons.

Voyons des situations concrètes où vous pourriez les utiliser :

Quand utiliser des simulations

Voici quelques cas de test où les simulations ont plus de sens :

• vous devez tester comment votre classe interagit avec ses dépendances
• vous devez vérifier les séquences complexes où une méthode spécifique est appelée plusieurs fois avec différents paramètres

Quand utiliser les talons

Vous pouvez créer des stubs avec PHPUnit très facilement :

use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    public function testMockExample(): void
    {
        $depencencyMock = $this->createMock(MyDependency::class);

        $dependencyMock->expects($this->exactly(2))
              ->method('someMethod')
              ->with('some parameter');

        $classToTest = new ClassToTest($dependencyMock);
   }
}

Voici quelques cas de test pour lesquels les stubs ont plus de sens :

• vous souhaitez tester la sortie ou l'état de votre code sans avoir besoin de vérifier les interactions
• vous devez tester certains calculs sans avoir besoin d'interagir avec la base de données réelle

En un mot, les stubs ne sont pas destinés à vérifier le comportement d'objets réels mais des états.

Réglage fin

L'objectif principal des tests unitaires est de garantir que chaque unité/composant fonctionne comme prévu, mais vous devrez maintenir ces tests en plus du code réel.

Les stubs peuvent simplifier la configuration des tests et sont très efficaces pour les scénarios simples dans lesquels vous n'avez pas besoin de suivre les appels de méthode et les interactions.

Cela peut éviter une complexité inutile en gardant certains de vos tests ciblés.

Conclure

Les simulations peuvent suivre les appels de méthode et leurs paramètres.

N'oubliez pas de renvoyer des valeurs représentatives de comportements réels. Sinon, vous pourriez vous retrouver avec un faux sentiment de sécurité.

Les simulations doivent être utilisées avec parcimonie pour éviter une complexité inutile lors de la maintenance.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!