Qu'est-ce qu'un "Stub"?
Donc, poursuivant ma résolution du nouvel an pour obtenir plus de TDD, je commence maintenant à travailler davantage avec Rhino Mocks .
Une chose que je tiens à faire est de m'assurer de bien comprendre ce que je vais faire, alors je voulais vérifier ma compréhension de ce que j'ai vu jusqu'à présent (et j'ai pensé qu'il serait bon de le faire ici en tant que Ressource).
Qu'est-ce qu'un "Stub"?
Martin Fowler a écrit un excellent article sur ce sujet. De cet article:
Meszaros utilise le terme Test Double comme terme générique désignant tout type d'objet simulé utilisé à la place d'un objet réel à des fins de test. Le nom vient de la notion de cascadeur double dans les films. (L'un de ses objectifs était d'éviter d'utiliser un nom déjà largement utilisé.) Meszaros a ensuite défini quatre types particuliers de doubles:
- Les objets factices sont distribués mais jamais réellement utilisés. Habituellement, ils sont simplement utilisés pour remplir des listes de paramètres.
- Les faux objets ont des implémentations fonctionnelles, mais prennent généralement un raccourci qui les rend impropres à la production (une base de données en mémoire est un bon exemple).
- Les stubs fournissent des réponses préenregistrées aux appels passés pendant le test, ne réagissant généralement pas du tout en dehors de ce qui est programmé pour le test. Les talons peuvent également enregistrer des informations sur les appels, tels qu'un talon de passerelle de messagerie qui se souvient des messages qu'il a "envoyés", ou peut-être uniquement du nombre de messages qu'il "a envoyés".
- Nous parlons ici de simulacres: objets préprogrammés avec des attentes qui constituent une spécification des appels qu’ils sont censés recevoir.
Pour le dire avec mes propres mots: les objets fictifs "s'attendent" à ce que certaines méthodes soient appelées à eux, et provoquent généralement l'échec du test unitaire si leurs attentes ne sont pas satisfaites. Les objets de raccord fournissent des réponses prédéfinies (et peuvent être générés automatiquement par des bibliothèques auxiliaires), mais en général, not ne provoque pas directement l'échec du test unitaire. Ils sont généralement simplement utilisés pour que l'objet que vous testez obtienne les données nécessaires à son travail.
Un "stub" est une implémentation d'une interface qui existe pour fournir des données/une réponse. Par exemple:
- un ensemble de données
- liste des utilisateurs
- un fichier xml
Normalement, cela serait fourni par un autre service (Web Service, une autre application, une base de données), mais afin d'améliorer la testabilité du code, les résultats sont "falsifiés".
Cela présente l’avantage majeur de permettre la formulation d’assertions dans des tests unitaires basés sur les données attendues. Si des erreurs surviennent en raison d’erreurs de données, des tests peuvent facilement être ajoutés, un nouveau stub créé (reproduisant l’erreur de données) et un code généré pour corriger l’erreur.
Stubs diffèrent de Mocks en ce qu'ils sont utilisés pour représenter et tester le état d'un objet, alors qu'un Mock teste son interaction .
Je crois que "stub" vient de STartUpBlock. il est utilisé pour faire référence à des parties de code générées automatiquement pour vous aider, en tant que développeur, à démarrer.
Un "stub" ou une "méthode de stub" est conçu pour être un code de démarrage ou un substitut temporaire du code non encore développé. C'est un code intégré généré par un IDE. Les méthodes de remplacement sont en réalité des méthodes utilisées pour tester les méthodes d'une classe particulière. Il est utilisé en entrant des valeurs pour les variables locales dans vos méthodes de développement actuelles et en vérifiant si le résultat est correct. C'est important pour trouver des bogues dans votre code.
Après quelques recherches et sur la base des fichiers de raccord auxquels j’ai été confronté au cours de ma vie de programmeur, je dirais qu’un fichier de raccord est tout simplement un fichier contenant tout ou partie de la mise en oeuvre d’un fichier. Cela aide les développeurs à commencer à coder.
J'ai récemment fait face à la question et reconnu que cette comparaison entre Stub et Driver est très claire et utile:
En gros, les stubs et les drivers sont des routines qui ne font rien d’autre que de se déclarer eux-mêmes et les paramètres qu’ils acceptent. Le reste du code peut alors prendre ces paramètres et les utiliser comme entrées.
+ --------- + ------------------------------- + ---- --------------------------- + | | Stub | Pilote | + --------- + ------------------------------- + - ----------------------------- + | Type | Codes factices | Codes factices | + --------- + ------------------------------- + - ------------------------------ + | Utilisé dans | Intégration descendante | Intégration ascendante | + --------- + ------------------------------- + ------------------------------- + | But | Pour permettre le test de la partie supérieure | Pour permettre le test de la partie inférieure | | | niveaux du code, lorsque le | niveaux du code, lorsque le | | | les niveaux inférieurs du code sont | les niveaux supérieurs du code sont | | | pas encore développé. | pas encore développé. | + --------- + ------------------------------- + --- ---------------------------- + | Exemple | A et B sont des composants. | A et B sont des composants. | | | A ---> B | A ---> B | | | | | | | A a été développé. | Il reste encore à développer. | | | B doit encore être développé | B a été développé. | | | Par conséquent, le stub est utilisé | Par conséquent, le pilote est utilisé | | | à la place de B pour l'imiter. | à la place de A pour l'imiter | | | | | | | A ---> Stub | Pilote ---> B | + --------- + ----------------------------- - + ------------------------------- +