Mock, Stub, Fake et Spy : les Test Doubles Expliqués

Un test pour place_order a besoin d’une passerelle de paiement, d’un client SMS et d’un calculateur de taxes. Branchez les vraies dépendances, et chaque exécution de test débite une carte et envoie un SMS. Un test unitaire doit s’exécuter en quelques millisecondes, sans réseau : les trois doivent donc être remplacées par autre chose. Cet « autre chose » existe en cinq variantes, chacune résolvant un problème différent, et les traiter comme interchangeables est la raison pour laquelle les débats « mets juste un mock » en revue de code tournent en rond.

Qu’est-ce qu’un test double

Gerard Meszaros a inventé le terme « test double » dans xUnit Test Patterns comme terme générique pour tout ce qui remplace une dépendance réelle pendant un test, à la manière d’une doublure qui remplace une actrice. Sur un tournage, on utilise des doublures différentes selon les plans : l’une n’a qu’à se tenir en arrière-plan avec la bonne coiffure, l’autre fait vraiment l’accident de voiture. Les test doubles se répartissent de la même façon. Dummy, stub, spy, fake et mock sont cinq rôles différents, et ce qui les distingue, c’est ce que le test vérifie, pas la sophistication de l’objet de substitution.

Voici la classe que testent tous les exemples ci-dessous. Trois de ses dépendances valent la peine d’être remplacées ; la quatrième n’a aucune importance :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

class PaymentDeclined(Exception):
    pass


class OrderProcessor:
    def __init__(self, gateway, sms_client, tax_calculator, logger):
        self.gateway = gateway
        self.sms_client = sms_client
        self.tax_calculator = tax_calculator
        self.logger = logger

    def place_order(self, customer_phone, subtotal):
        total = self.tax_calculator.total_with_tax(subtotal)
        try:
            charge_id = self.gateway.charge(total)
        except PaymentDeclined:
            self.logger.warning("payment declined for %s", customer_phone)
            raise
        self.sms_client.send(customer_phone, f"Order confirmed, charged ${total:.2f}")
        return charge_id

logger n’intervient que sur le chemin d’erreur. Cela compte pour le premier exemple.

Deux petites doublures sont réutilisées dans les tests suivants ; elles sont donc définies une seule fois ici :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from unittest.mock import Mock, create_autospec


class StubGateway:
    def __init__(self, charge_id):
        self.charge_id = charge_id

    def charge(self, amount):
        return self.charge_id


class StubTaxCalculator:
    def __init__(self, total):
        self.total = total

    def total_with_tax(self, subtotal):
        return self.total

Qu’est-ce qu’un objet dummy dans les tests

Un dummy n’est passé que pour satisfaire un paramètre que le test n’exerce jamais. Il ne fait rien et ne vérifie rien. Le test du chemin heureux ci-dessous n’atteint jamais la branche d’exception, donc logger peut être n’importe quoi qui survit à une affectation d’attribut :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

def test_place_order_returns_the_charge_id():
    dummy_logger = object()  # jamais appelé sur ce chemin
    processor = OrderProcessor(
        gateway=StubGateway(charge_id="ch_1"),
        sms_client=Mock(),
        tax_calculator=StubTaxCalculator(total=108.00),
        logger=dummy_logger,
    )

    charge_id = processor.place_order("+15551234567", subtotal=100.00)

    assert charge_id == "ch_1"

object() fonctionne parce que rien n’appelle de méthode sur lui. Si un changement ultérieur faisait aussi logguer place_order sur le chemin de succès, ce test échouerait avec une AttributeError. Cet échec est utile : il indique que le dummy a cessé d’être un dummy.

Qu’est-ce qu’un stub dans un test unitaire

Un stub renvoie une réponse préfabriquée pour que le reste du test reste déterministe. Le vrai calculateur de taxes pourrait appeler une API de taux de taxe. Le test ne veut pas de ça, donc StubTaxCalculator renvoie 108.00 quel que soit le sous-total reçu. Vous l’avez déjà vu à l’œuvre dans le test du dummy ci-dessus, avec StubGateway qui fait le même travail pour charge.

Rien ne vérifie si total_with_tax a été appelé, ni avec quel argument. Un stub fournit au code testé une entrée contrôlée ; il ne vérifie jamais une interaction. C’est la frontière entre un stub et les trois doublures suivantes.

Qu’est-ce qu’un test spy

Un spy enregistre les appels qu’il reçoit afin que le test puisse les examiner après l’exécution du code testé. unittest.mock.Mock enregistre automatiquement chaque appel, donc la plupart des suites Python l’utilisent comme spy même quand le mot n’apparaît jamais dans le test :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def test_place_order_sends_a_confirmation_sms():
    sms_spy = Mock()
    processor = OrderProcessor(
        gateway=StubGateway(charge_id="ch_1"),
        sms_client=sms_spy,
        tax_calculator=StubTaxCalculator(total=108.00),
        logger=object(),
    )

    processor.place_order("+15551234567", subtotal=100.00)

    sms_spy.send.assert_called_once_with(
        "+15551234567", "Order confirmed, charged $108.00"
    )

Rien n’a été configuré sur sms_spy avant l’appel. Il a accepté ce qu’on lui a donné, l’a enregistré, et le test l’a interrogé après coup.

Qu’est-ce qu’un objet fake dans les tests

Un stub ne peut pas vous dire si deux débits consécutifs obtiennent deux identifiants différents, car il ne connaît qu’une seule valeur. Quand un test a besoin d’un comportement sur plusieurs appels, c’est un fake qu’il faut : une petite implémentation qui fonctionne vraiment.

1
2
3
4
5
6
7
8

class FakeGateway:
    def __init__(self):
        self.charges = []

    def charge(self, amount):
        charge_id = f"ch_{len(self.charges) + 1}"
        self.charges.append((charge_id, amount))
        return charge_id

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

def test_two_orders_get_two_different_charge_ids():
    gateway = FakeGateway()
    processor = OrderProcessor(
        gateway=gateway,
        sms_client=Mock(),
        tax_calculator=StubTaxCalculator(total=108.00),
        logger=object(),
    )

    first_id = processor.place_order("+15551234567", subtotal=100.00)
    second_id = processor.place_order("+15557654321", subtotal=100.00)

    assert first_id != second_id
    assert gateway.charges == [(first_id, 108.00), (second_id, 108.00)]

FakeGateway ne fait aucun appel réseau et n’a aucun processeur de paiement derrière lui, mais il conserve un état comme le ferait le vrai. Le test avait justement besoin de cet état, et un stub n’aurait pas pu le fournir.

Qu’est-ce qu’un objet mock

Dans la définition de Meszaros, un mock porte ses attentes dans le test : les règles d’un appel valide sont fixées avant l’exécution du code, et un appel qui les enfreint échoue immédiatement. unittest.mock est plus souple que ça, puisque l’assertion se fait toujours après coup, mais create_autospec vous donne la partie qui compte. Il construit la doublure à partir d’une vraie classe, donc chaque appel est vérifié par rapport aux vraies signatures de méthode au moment où il se produit :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

class Gateway:
    def charge(self, amount: float) -> str:
        raise NotImplementedError


def test_place_order_charges_the_amount_after_tax():
    gateway = create_autospec(Gateway, instance=True)
    gateway.charge.return_value = "ch_1"
    processor = OrderProcessor(
        gateway=gateway,
        sms_client=Mock(),
        tax_calculator=StubTaxCalculator(total=108.00),
        logger=object(),
    )

    processor.place_order("+15551234567", subtotal=100.00)

    gateway.charge.assert_called_once_with(108.00)

Changez place_order pour appeler self.gateway.charge(total, currency="usd"), et ce test échoue avec une TypeError à l’intérieur de place_order, parce que Gateway.charge n’accepte pas d’argument currency. Imaginez maintenant un simple Mock() au même endroit, avec quelqu’un qui met à jour l’assertion pour correspondre au nouvel appel. Le test passe, et le code casse dès qu’il rencontre la vraie passerelle. Un spy confirme qu’un appel a eu lieu. Un mock autospécifié confirme en plus que cet appel est bien un appel que le véritable objet accepterait.

Mock vs stub vs spy vs fake : tableau comparatif

gateway a été un stub, un fake et un mock dans trois tests de la même classe. La doublure suit ce que le test vérifie, pas la dépendance.

Quand les test doubles rendent les tests pires

Mocker chaque collaborateur couple le test à la façon dont le code est écrit plutôt qu’à ce qu’il fait. Ajoutez un test qui vérifie que total_with_tax est appelé exactement une fois, puis modifiez place_order pour l’appeler une seconde fois à des fins de logging : le test casse, alors que rien de ce qui compte pour un utilisateur n’a changé. Le test avec le fake ci-dessus n’a pas ce problème, car il vérifie le résultat (deux identifiants de débit distincts, les bons montants enregistrés) plutôt que la forme de l’appel.

Mocker une bibliothèque que vous ne possédez pas pose le même problème, un niveau plus haut. Autospécifiez directement un client tiers, et chaque test qui le touche dépend des signatures de méthode de cette bibliothèque ; une montée de version mineure qui renomme un paramètre casse des tests dans toute la suite. Enveloppez plutôt la bibliothèque dans votre propre petite interface, et doublez celle-ci. Quand la bibliothèque change, seul le wrapper change.

Parfois, le bon nombre de doublures est zéro. Si la vraie dépendance est déjà rapide et sans effet de bord, comme une fonction pure ou une connexion SQLite en mémoire, la doubler ajoute de l’indirection sans rien attraper. Les doublures sont faites pour les dépendances lentes, distantes, non déterministes, ou qui ont des effets de bord que vous ne voulez pas dans une exécution de test.

Comment choisir le bon test double

Partez de ce que le test vérifie, pas de ce qui semble le plus sûr à simuler. Si vous avez besoin d’une entrée prévisible pour qu’une assertion ultérieure tienne, stubbez-la. Pour confirmer que le SMS est parti, espionnez-le. Si la dépendance doit se comporter correctement sur plusieurs appels, écrivez un fake une seule fois et réutilisez-le partout où cette dépendance apparaît. Et quand un appelant qui passe de mauvais arguments doit faire échouer le test avant qu’il n’échoue en production, utilisez un mock autospécifié.

Rien de tout cela ne fonctionne sur une classe qui construit elle-même ses dépendances en interne, car il n’y a nulle part où glisser une doublure. C’est le problème que résout la dependency injection, et c’est la première chose à corriger si une classe résiste à toutes les doublures de cet article. Une fois la couture en place, décidez quelle doublure appartient à quel niveau de test. Si vous travaillez en test-first, vous aurez recours aux doublures tôt, puisque le test existe avant qu’il y ait du vrai code à appeler.

Articles associés

• Qu’est-ce que la Dependency Injection (avec Exemples)
• Tests Unitaires vs Tests d’Intégration vs Tests End-to-End
• Qu’est-ce que le TDD et Comment Marche le Red-Green-Refactor