Comprendre les objets simulés dans les tests PHPUnit

Lors de l'écriture de tests unitaires, un défi clé est de garantir que vos tests se concentrent sur le code testé sans interférence de systèmes ou de dépendances externes. C'est là que les objets simulés entrent en jeu dans PHPUnit. Ils vous permettent de simuler le comportement d'objets réels de manière contrôlée, rendant vos tests plus fiables et plus faciles à maintenir. Dans cet article, nous explorerons ce que sont les objets fictifs, pourquoi ils sont utiles et comment les utiliser efficacement dans PHPUnit.

Que sont les objets fictifs ?

Les objets simulés sont des versions simulées d'objets réels utilisées dans les tests unitaires. Ils vous permettent de :

• Isolez le code sous test : les objets simulés simulent le comportement des dépendances, garantissant que les résultats des tests ne sont pas affectés par la mise en œuvre réelle de ces dépendances.
• Comportement de dépendance de contrôle : vous pouvez spécifier comment la simulation doit se comporter lorsque certaines méthodes sont appelées, vous permettant de tester différents scénarios.
• Vérifier les interactions : les simulations suivent les appels de méthode et leurs paramètres, garantissant que le code testé interagit correctement avec ses dépendances.

Pourquoi utiliser des objets simulés ?

Les simulations sont particulièrement utiles dans les scénarios suivants :

• Dépendances complexes : si votre code repose sur des systèmes externes tels que des bases de données, des API ou des services tiers, les objets fictifs simplifient les tests en éliminant le besoin d'interagir avec ces systèmes.
• Tests d'interaction : les simulations vous permettent de vérifier que des méthodes spécifiques sont appelées avec les arguments corrects, garantissant ainsi que votre code se comporte comme prévu.
• Exécution des tests plus rapide : les opérations du monde réel telles que les requêtes de base de données ou les requêtes API peuvent ralentir les tests. Se moquer de ces dépendances garantit une exécution plus rapide des tests.

Stubbing ou moquerie : quelle est la différence ?

Lorsque vous travaillez avec des objets fictifs, vous rencontrerez deux termes : stubbing et mocking :

• Stubbing : fait référence à la définition du comportement des méthodes sur un objet fictif, par exemple, demander à une méthode de renvoyer une valeur spécifique.
• Mocking : implique de définir des attentes sur la façon dont les méthodes doivent être appelées, par exemple, en vérifiant le nombre d'appels de méthode et leurs paramètres.

Comment créer et utiliser des objets simulés dans PHPUnit

PHPUnit facilite la création et l'utilisation d'objets fictifs avec la méthode createMock(). Vous trouverez ci-dessous quelques exemples qui montrent comment travailler efficacement avec des objets fictifs.

Exemple 1 : utilisation de base d'un objet fictif

Dans cet exemple, nous créons un objet fictif pour une dépendance de classe et spécifions son comportement.

use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    public function testMockExample()
    {
        // Create a mock for the SomeClass dependency
        $mock = $this->createMock(SomeClass::class);

        // Specify that when the someMethod method is called, it returns 'mocked value'
        $mock->method('someMethod')
             ->willReturn('mocked value');

        // Pass the mock object to the class under test
        $unitUnderTest = new ClassUnderTest($mock);

        // Perform the action and assert that the result matches the expected value
        $result = $unitUnderTest->performAction();
        $this->assertEquals('expected result', $result);
    }
}

Explication :

• createMock(SomeClass::class) crée un objet fictif pour SomeClass.
• method('someMethod')->willReturn('mocked value') définit le comportement du mock.
• L'objet fictif est transmis à la classe testée, garantissant que la véritable implémentation de SomeClass n'est pas utilisée.

Exemple 2 : vérification des appels de méthode

Parfois, vous devez vérifier qu'une méthode est appelée avec les paramètres corrects. Voici comment procéder :

public function testMethodCallVerification()
{
    // Create a mock object
    $mock = $this->createMock(SomeClass::class);

    // Expect the someMethod to be called once with 'expected argument'
    $mock->expects($this->once())
         ->method('someMethod')
         ->with($this->equalTo('expected argument'))
         ->willReturn('mocked value');

    // Pass the mock to the class under test
    $unitUnderTest = new ClassUnderTest($mock);

    // Perform an action that calls the mock's method
    $unitUnderTest->performAction();
}

Points clés :

• attend($this->once()) garantit que someMethod est appelé exactement une fois.
• with($this->equalTo('expected argument')) vérifie que la méthode est appelée avec l'argument correct.

Exemple : test avec PaymentProcessor

Pour démontrer l'application dans le monde réel des objets fictifs, prenons l'exemple d'une classe PaymentProcessor qui dépend d'une interface PaymentGateway externe. Nous souhaitons tester la méthode processPayment de PaymentProcessor sans nous appuyer sur la mise en œuvre réelle de PaymentGateway.

Voici la classe PaymentProcessor :

class PaymentProcessor
{
    private $gateway;

    public function __construct(PaymentGateway $gateway)
    {
        $this->gateway = $gateway;
    }

    public function processPayment(float $amount): bool
    {
        return $this->gateway->charge($amount);
    }
}

Maintenant, nous pouvons créer une simulation pour PaymentGateway afin de tester la méthode processPayment sans interagir avec la passerelle de paiement réelle.

Test du PaymentProcessor avec des objets simulés

use PHPUnit\Framework\TestCase;

class PaymentProcessorTest extends TestCase
{
    public function testProcessPayment()
    {
        // Create a mock object for the PaymentGateway interface
        $gatewayMock = $this->createMock(PaymentGateway::class);

        // Define the expected behavior of the mock
        $gatewayMock->method('charge')
                    ->with(100.0)
                    ->willReturn(true);

        // Inject the mock into the PaymentProcessor
        $paymentProcessor = new PaymentProcessor($gatewayMock);

        // Assert that processPayment returns true
        $this->assertTrue($paymentProcessor->processPayment(100.0));
    }
}

Répartition du test :

• createMock(PaymentGateway::class) creates a mock object simulating the PaymentGateway interface.
• method('charge')->with(100.0)->willReturn(true) specifies that when the charge method is called with 100.0 as an argument, it should return true.
• The mock object is passed to the PaymentProcessor class, allowing you to test processPayment without relying on a real payment gateway.

Verifying Interactions

You can also verify that the charge method is called exactly once when processing a payment:

public function testProcessPaymentCallsCharge()
{
    $gatewayMock = $this->createMock(PaymentGateway::class);

    // Expect the charge method to be called once with the argument 100.0
    $gatewayMock->expects($this->once())
                ->method('charge')
                ->with(100.0)
                ->willReturn(true);

    $paymentProcessor = new PaymentProcessor($gatewayMock);
    $paymentProcessor->processPayment(100.0);
}

In this example, expects($this->once()) ensures that the charge method is called exactly once. If the method is not called, or called more than once, the test will fail.

Example: Testing with a Repository

Let’s assume you have a UserService class that depends on a UserRepository to fetch user data. To test UserService in isolation, you can mock the UserRepository.

class UserService
{
    private $repository;

    public function __construct(UserRepository $repository)
    {
        $this->repository = $repository;
    }

    public function getUserName($id)
    {
        $user = $this->repository->find($id);
        return $user->name;
    }
}

To test this class, we can mock the repository:

use PHPUnit\Framework\TestCase;

class UserServiceTest extends TestCase
{
    public function testGetUserName()
    {
        // Create a mock for the UserRepository
        $mockRepo = $this->createMock(UserRepository::class);

        // Define that the find method should return a user object with a predefined name
        $mockRepo->method('find')
                 ->willReturn((object) ['name' => 'John Doe']);

        // Instantiate the UserService with the mock repository
        $service = new UserService($mockRepo);

        // Assert that the getUserName method returns 'John Doe'
        $this->assertEquals('John Doe', $service->getUserName(1));
    }
}

Best Practices for Using Mocks

1. Use Mocks Only When Necessary: Mocks are useful for isolating code, but overuse can make tests hard to understand. Only mock dependencies that are necessary for the test.
2. Focus on Behavior, Not Implementation: Mocks should help test the behavior of your code, not the specific implementation details of dependencies.
3. Avoid Mocking Too Many Dependencies: If a class requires many mocked dependencies, it might be a sign that the class has too many responsibilities. Refactor if needed.
4. Verify Interactions Sparingly: Avoid over-verifying method calls unless essential to the test.

Conclusion

Mock objects are invaluable tools for writing unit tests in PHPUnit. They allow you to isolate your code from external dependencies, ensuring that your tests are faster, more reliable, and easier to maintain. Mock objects also help verify interactions between the code under test and its dependencies, ensuring that your code behaves correctly in various scenarios

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!