À quoi bon tester de faux référentiels?

Question

J'ai essayé de pousser mon mentalité en développant à la maison pour être plus orienté vers TDD et un peu DDD.

Une chose que je ne comprends pas, c'est pourquoi vous créez un faux référentiel à tester? Je ne l'ai pas vraiment examiné beaucoup mais sûrement l'idée du test est de découpler votre code (vous donnant plus de flexibilité), de réduire le code nécessaire et de réduire le nombre de bugs.

Est-ce que quelqu'un peut remplir mon cerveau stupide pour savoir pourquoi certains aiment tester de faux référentiels? J'aurais pensé que tester contre une base de données réelle est une meilleure alternative à la création d'un faux parce que vous savez alors que cela fonctionne contre votre magasin de données du monde 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 mettre en place un état connu dans le référentiel.

Le faux dépôt sera plus rapide de plusieurs ordres de grandeur qu'une vraie base de données.

Le faux référentiel ne remplacera PAS les tests système qui incluront votre base de données.

Answer 2

Comme je le vois, il y a deux raisons pour lesquelles vous vraiment grandes ressources truquées effectuer le test:

• Il fait des tests unitaires plus rapide lorsque vous avez un moquaient contre E/S lent ou base de données. Cela ne ressemble peut-être à rien si vous avez une petite suite de tests, mais quand vous faites jusqu'à 500 tests unitaires, cela commence à faire la différence. Dans une telle quantité, les tests qui s'exécutent sur la base de données commencent à prendre plusieurs secondes. Les programmeurs sont paresseux et veulent que les choses aillent vite, donc si exécuter une suite de tests prend plus de 10 secondes, vous ne serez plus content de faire TDD.
• Cela vous oblige à réfléchir à la conception de votre code pour faciliter les modifications. La conception par contrat et l'injection de dépendances deviennent aussi beaucoup plus faciles à faire si vous avez implémenté des interfaces ou des classes abstraites. Si cela est fait correctement, une telle conception facilite la conformité aux changements de votre code.

Le seul inconvénient est l'évidence un:

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

... et c'est ce que les tests d'intégration sont pour.

Answer 3

J'upvoted la réponse de girafe, mais veulent juste ajouter quelques points:

• Chaque développeur peut utiliser un référentiel de simulation/faux pour son/sa propre unité test sans interférer avec les essais étant fait par d'autres développeurs sur le même projet.

• En utilisant une maquette locale/dépôt de faux renforce l'utilisateur d'une couche abstraction de données, ce qui est une bonne pratique de conception .

À titre d'exemple, je l'ai utilisé quelque chose d'aussi simple que HashMap pour mettre en œuvre une maquette de la couche d'accès aux données. Cela rend extrêmement facile facile pour chaque test unitaire pour s'assurer que exactement les conditions nécessaires existent pour son but, et de vérifier que les bons appels ont été faits sur la couche d'accès aux données.