Meilleures pratiques pour écrire des objets de choc dans Tdd pour les tests logiciels d'ingénierie

• Dummy – Un objet passé mais jamais utilisé, généralement pour satisfaire les signatures de méthode.
• Stub – Fournit des réponses en conserve aux appels effectués pendant le test, souvent utilisés pour contrôler les entrées indirectes.
• Spy – Consigne les informations sur la façon dont il a été appelé, permettant une vérification ultérieure.
• Mock – Préprogrammé avec des attentes sur les appels à faire et le nombre de fois; il affirme que l'interaction a eu lieu comme prévu.
• Fake – Une implémentation légère (p. ex., une base de données en mémoire) qui ne convient pas à la production mais qui est utile pour les essais.

En TDD strict, les maquettes et les espions sont les principaux outils pour les tests basés sur l'interaction, tandis que les talons soutiennent les tests basés sur l'état.

Les cadres de simulation modernes (p. ex., Mockito, Jest, unittest.mock) brouillent ces lignes en offrant des fonctionnalités combinées, mais la clarté conceptuelle demeure critique. Un objet de simulation dans TDD devrait vérifier que le système en cours d'essai (SUT) interagit avec ses dépendances de la manière prévue – appelant des méthodes spécifiques avec des arguments corrects et respectant l'ordre ou la fréquence des appels.

Meilleures pratiques de base pour écrire des objets de choc

Les pratiques suivantes sont distillées à partir d'années d'expérience de l'industrie et de sagesse communautaire. L'adhésion à eux rendra vos tests plus fiables, lisibles et résilients à la refacturation.

1. Gardez les mocks simples et concentrés

Concevoir chaque maquette pour simuler seulement le comportement exact requis par le test. Éviter de surcharger les maquettes avec des talons inutiles, des valeurs de retour ou des vérifications. Lorsqu'une maquette fait trop, l'intention du test devient obscurcie et les coûts de maintenance augmentent. Par exemple, si la SUT appelle seulement une méthode de dépôt , la maquette ne devrait pas aussi définir le comportement pour à moins que cette méthode ne soit exercée dans le même test.

En outre, préférez utiliser des réponses par défaut ou des maquettes clémentes (où le cadre le permet) pour éviter de casser les tests lorsque la SUT évolue. Dans Mockito, empêche les erreurs inutiles lorsque les méthodes stubpées ne sont pas appelées; dans Jest, retourne par défaut. Cela maintient les tests concentrés sur l'interaction qui compte.

2. Utiliser des conventions de désignation claire

Le nom d'une variable simulée devrait communiquer son rôle et la dépendance qu'elle remplace. Au lieu de ou , utiliser des noms descriptifs comme ou . Ceci est particulièrement important dans les grandes suites de test où les développeurs analysent rapidement le code de configuration.

Pour les méthodes simulées, si vous créez des implémentations simulées personnalisées (rarement nécessaires avec des frameworks), utilisez des noms de méthode qui indiquent clairement le comportement simulé, comme ou . Évitez les noms génériques comme qui cachent les détails.

3. Vérifier explicitement les interactions

Le but principal d'une maquette est d'affirmer que des interactions particulières se sont produites. Utilisez les fonctions de vérification de votre cadre de maquette pour confirmer que des méthodes spécifiques ont été appelées avec des arguments attendus, le nombre d'appels ou l'ordre.

Mockito.verify(mockService, times(1)).processPayment(anyString(), eq(100.0));

Dans Jest:

expect(mockService.processPayment).toHaveBeenCalledTimes(1);
expect(mockService.processPayment).toHaveBeenCalledWith('order-123', 100.0);

Attention à vérifier seulement ce qui est essentiel au contrat comportemental. La survérification (par exemple, vérifier qu'aucune autre méthode n'a été appelée via sans discrimination) peut rendre les tests fragiles.

4. Évitez les chocs surmenés

Le mocking n'est pas un choix par défaut. Le mocking excessif conduit à des tests étroitement couplés aux détails de l'implémentation, rendant la refacturation douloureuse.

• Mock only external limits – Dépendances qui croisent les limites de processus, de réseau ou d'entrées/sorties (p. ex., un client de base de données, une API REST, un système de fichiers).
• Préférez les objets réels pour les laborateurs de collage en cours de fabrication – Si un collaborateur est simple, rapide et sans effets secondaires (par exemple, un objet de valeur ou une classe d'utilité), utilisez-le directement plutôt que de le railler.
• Évitez les types de moqueries que vous possédez – Si vous contrôlez l'implémentation d'une dépendance, examinez si un faux (une version légère en mémoire) serait plus durable qu'une maquette avec des dizaines de talons.
• Utilisez des tests d'intégration pour des workflows complexes – Bien que les simulations soient idéales pour les tests unitaires, les tests d'intégration (en utilisant des dépendances réelles ou conteneurisées) capturent les bogues de coordination qui ne peuvent pas être utilisés.

Une bonne règle de pouce : si vous vous trouvez à écrire 20 lignes de configuration simulée pour un test unitaire, il se peut que ce soit un signe que le SUT a trop de dépendances ou que vous devriez envisager une approche de test différente.

5. Dépendances d'injecter explicitement

Les objets Mock ne fonctionnent que lorsque le SUT accepte ses dépendances par injection de constructeur, par paramètres de méthode ou (moins idéalement) par injection de setter. Les méthodes statiques, l'état global et la création d'objets à l'intérieur du SUT (en utilisant ) se moquent des anti-patterns. Ecrivez votre code de production avec injection de dépendance (DI) à l'esprit. Par exemple :

public class OrderService {
 private final PaymentGateway paymentGateway;
 public OrderService(PaymentGateway paymentGateway) {
 this.paymentGateway = paymentGateway;
 }
 // ...
}

Cette conception permet aux tests de remplacer facilement une maquette . Si votre base de codes utilise un conteneur DI, assurez-vous que la configuration des tests peut remplacer les implémentations réelles par des maquettes.

6. Utiliser des données réalistes et des données de cas de bord

Les Mocks doivent retourner les données qui reflètent les valeurs de production, y compris les types, les plages et les structures. Évitez d'utiliser des valeurs de placeholder triviales comme des chaînes vides ou 0 pour chaque test, sauf si tel est le scénario testé. Utilisez des charges utiles réalistes pour découvrir les erreurs d'appariement tôt. Par exemple, si une méthode s'attend à une liste de commandes, retournez une liste avec plusieurs éléments, et non une liste vide, à moins que le test ne couvre explicitement le cas vide.

Une erreur courante est de se moquer d'un dépôt pour toujours renvoyer un objet lorsque l'implémentation réelle peut retourner ou lancer une exception. Tests puis passer, mais le code de production échoue. Utilisez votre simulation pour simuler systématiquement les chemins de succès et d'échec.

7. Réinitialiser les chocs entre les essais

Dans toute suite de test, les maquettes devraient être fraîches pour chaque cas de test afin d'éviter les fuites d'état. La plupart des cadres modernes offrent des annotations ou des méthodes de configuration pour réinitialiser automatiquement les maquettes. Dans JUnit 5 avec Mockito, utilisez et annotations – les maquettes sont réinitialisées par test.

Outils et cadres pour le mocking

Choisir le bon outil de simulation simplifie la mise en œuvre des meilleures pratiques. Ci-dessous sont les principaux cadres dans les langues populaires, ainsi que des conseils sur l'utilisation efficace.

Java: Mockito