Quel est l'intérêt de tester de faux référentiels?

Question

J'essayais de pousser ma mentalité lorsque je développais chez moi pour être plus orienté vers le TDD et un peu DDD.

Une chose que je ne comprends pas, cependant, est la raison pour laquelle vous créeriez un faux référentiel à tester. Je n'ai pas beaucoup étudié la question, mais les tests ont certainement pour but de découpler votre code (pour vous donner plus de flexibilité), de réduire le code nécessaire et de réduire le nombre de bogues.

Alors, est-ce que quelqu'un peut expliquer dans mon cerveau stupide pourquoi certains aiment tester de faux référentiels? J'aurais pensé que les tests sur une base de données réelle sont une bien meilleure alternative à la création d'une fausse, car vous SAVEZ alors que cela fonctionne avec votre magasin de données réel.

Answer 1

Le faux référentiel vous permet de tester uniquement le code de votre application.

Le faux référentiel signifie qu'un test automatisé peut facilement configurer un état connu dans le référentiel.

Le faux référentiel sera plusieurs fois plus rapide qu'une vraie base de données.

Le faux référentiel ne remplace PAS les tests du système incluant votre base de données.

Answer 2

Comme je le vois, il existe deux très grandes raisons pour lesquelles vous testez des ressources fictives:

• Rend les tests unitaires plus rapides lorsque vous vous moquez de bases de données ou d'E / S lentes. Cela peut ne ressembler à rien si vous avez une petite suite de tests, mais lorsque vous êtes à plus de 500 tests unitaires, cela commence à faire une différence. Dans une telle quantité, les tests exécutés sur la base de données commenceront à prendre plusieurs secondes. Les programmeurs sont paresseux et veulent que les choses aillent vite alors si exécuter une suite de tests prend plus de 10 secondes, vous ne serez plus heureux de faire TDD.
• Cela vous oblige à réfléchir à la conception de votre code pour faciliter les modifications. L'injection de conception par contrat et de dépendance devient également beaucoup plus facile à effectuer si vous avez implémenté des interfaces ou des classes abstraites. Si vous le faites correctement, cette conception facilite la conformité aux modifications de votre code.

Le seul inconvénient est l'évident:

• Comment pouvez-vous être sûr que cela fonctionne vraiment?

... et c’est à cela que servent les tests d’intégration .

Answer 3

J'ai voté pour la réponse de Giraffe, mais je voudrais ajouter quelques points seulement:

• Chaque développeur peut utiliser un simulacre / faux référentiel pour sa propre unité tester sans interférer avec le tests effectués par d'autres développeurs sur le même projet.

• Utilisation d'un référentiel local simulé / simulé renforce l'utilisateur d'une donnée couche d'abstraction, ce qui est bon pratique de conception.

Par exemple, j'ai utilisé quelque chose d'aussi simple qu'un HashMap pour implémenter une maquette de la couche d'accès aux données. Cela rend extrêmement extrêmement facile, pour chaque test unitaire, de s'assurer que les conditions nécessaires sont remplies et de vérifier que les bons appels ont été effectués sur la couche d'accès aux données.