Qu'est-ce que les Moqueries?
8 réponses
Prologue: Si vous recherchez le nom se moquer de dans le dictionnaire, vous trouverez que l'une des définitions du mot est quelque chose comme une imitation .
Moquerie est principalement utilisé dans les tests unitaires. Un objet à l'essai peut avoir des dépendances sur d'autres objets (complexes). Pour isoler le comportement de l'objet vous voulez remplacer les autres objets par des moqueries qui simulent le comportement du des objets réels. Cela est utile si les objets réels ne peuvent pas être incorporés dans le test unitaire.
bref, se moquer c'est créer des objets qui simulent le comportement d'objets réels.
parfois, vous pouvez faire la distinction entre moquerie par opposition à entêtement . Il peut y avoir un certain désaccord sur ce sujet, mais ma définition d'un talon est un" minimum " simulé objet. Le talon implémente juste assez de comportement pour permettre à l'objet en test d'exécuter le test.
une maquette est comme un talon, mais le test vérifiera également que l'objet testé appelle la maquette comme prévu. Une partie du test consiste à vérifier que la maquette a été utilisée correctement.
pour donner un exemple: vous pouvez couper une base de données en implémentant une structure simple en mémoire pour stocker des enregistrements. L'objet testé peut alors lire et écrire des enregistrements talon de la base de données pour lui permettre d'exécuter le test. Cela pourrait tester un certain comportement de l'objet non lié à la base de données et le talon de la base de données serait inclus juste pour laisser le test s'exécuter.
Si vous voulez vérifier que l'objet sous test écrit certaines données spécifiques à la base de données, vous aurez à se moquer de la base de données. Votre test incorporerait alors des assertions sur ce qui a été écrit dans la simulation de base de données.
D'autres réponses expliquent ce qu'est la moquerie. Permettez-moi de vous guider à travers elle avec un exemple . Et croyez-moi, c'est beaucoup plus simple que vous le pensez.
tl;dr il s'agit d'une sous-classe de la classe d'origine. Il a d'autres données injectées de sorte que vous évitez de tester les pièces injectées et uniquement focus sur l'essai du reste du code.
disons vous écrivez une application iOS et avez des appels réseau.Votre travail consiste à tester votre application . Tester / identifier si les appels réseau fonctionnent comme prévu N'est pas de votre responsabilité . C'est la responsabilité d'une autre partie (équipe du serveur) de le tester. Vous devez supprimer cette dépendance (réseau) et continuer à tester tout votre code qui fonctionne autour de it.
un appel réseau peut retourner différents codes d'état 404, 500, 200, 303, etc. avec une réponse JSON.
de Votre application suppose de travailler pour tous d'entre eux (en cas d'erreurs, votre application doit jeter son erreur). Ce que vous faites avec moquerie, c'est de créer des réponses réseau 'imaginaires-similaires aux vraies' (comme un code 200 avec un fichier JSON) et tester votre code sans 'faire l'appel réseau réel et attendre votre réponse réseau'. Vous codez/renvoyez manuellement la réponse réseau pour tous types de réponses réseau et voir si votre application fonctionne comme vous l'attendez. (vous jamais assumer/tester un 200 avec des données incorrectes, parce que ce n'est pas votre responsabilité, votre responsabilité est de tester votre "151960920 app lance avec un 200 correct, ou dans le cas d'un 400, 500, vous tester si votre application lance la bonne erreur)
cette création imaginaire-similaire au réel est connue sous le nom de moquerie.
pour ce faire, vous ne peut pas utiliser votre code original (votre code original n'a pas les réponses pré-insérées, Non?). Vous doit ajouter quelque chose, injectez/insérez ces données factices qui ne sont pas normalement nécessaires (ou une partie de votre classe).
donc vous sous-classe la classe d'origine et ajouter quoi que ce soit (ici étant le HTTPResponse réseau, données ou en cas d'échec, vous passez le errorString correct, HTTPResponse) vous avez besoin à elle et puis "tester la sous-classe" ie la classe moqué .
vous ne testez plus la classe d'origine. La sous-classe/moquée est testée pour le compte de la classe d'origine
pour faire court, la moquerie est à simplifier et limite ce que vous testez et aussi vous faire nourrir ce qu'une classe dépend de. Dans cet exemple vous éviter les tests le réseau s'appelle , et à la place test si votre application fonctionne ou non comme vous l'attendez avec les sorties/réponses injectées -- par moquerie classes
inutile de dire que vous testez chaque réponse réseau séparément.
Maintenant, une question que j'ai toujours eu dans mon esprit était: Les contrats/fin les points et essentiellement la réponse JSON de mon API sont mis à jour constamment. Comment puis-je faire des tests unitaires qui prennent cela en considération?
pour développer plus sur ce point: disons que le modèle nécessite une clé/champ nommé username . Vous testez ceci et votre test est réussi.
2 semaines plus tard backend change le nom de la clé en id . Vos tests sont toujours réussis. droit? ou pas?
est-ce la responsabilité du développeur d'arrière-plan de mettre à jour les Mock. Devrait-il être de la partie de notre accord pour qu'ils fournissent des moqueries à jour?
la réponse à la question ci-dessus est que: tests unitaires + votre processus de développement en tant que développeur côté client devrait/devrait attraper réponse périmée. Si vous me demandez comment? la réponse est:
notre application actuelle échouerait (ou ne manquerait pas encore d'avoir le comportement désiré) sans utiliser des API mises à jour...donc, si cela échoue...nous apporterons des changements à notre code de développement. Ce qui nous amène à nouveau à nos tests défaillant....qui nous nous allons de les corriger. (En fait, si nous devons faire le processus TDD correctement, nous ne devons pas écrire de code sur le champ à moins que nous écrivions le test pour lui...et le voir échouer et ensuite aller et écrire le code de développement réel pour elle.
tout cela signifie que backend n'a pas à dire:"Hé, nous avons mis à jour les mocks "...it finalement se produit à travers votre développement de code/débogage. Parce que tout cela fait partie du processus de développement! Bien que si backend fournit la réponse moquée pour vous alors il est plus facile.
mon point de vue là-dessus c'est inefficace de trouver un script pour obtenir un mock mis à jour de votre API. Ne mettez pas 100% de votre effort sur faire les choses automatiquement et sans aucune interaction humaine est ce que TDD est au sujet. Une partie du processus est manuel mises à jour de JSONs et d'avoir de courtes réunions pour s'assurer que leurs valeurs sont à jour.
cette section a été écrite grâce à une discussion détendue dans notre groupe CocoaHead meetup
pour iOS devs seulement:
un très bon exemple de moquerie est ce exposé pratique axé sur le Protocole par Natasha Muraschev juste passer à la minute 18:30.
j'aime vraiment cette partie de la transcription:
Parce que c'est un test...nous voulons nous assurer que la fonction
getde laGettableest appelé, parce qu'il peut revenir et la fonction pourrait théoriquement assigner un tableau d'articles alimentaires de n'importe où . Nous cents cinquante et une million neuf cent soixante dix mille neuf cent vingt"
Il ya beaucoup de réponses sur SO et de bons messages sur le web sur la moquerie. Un endroit que vous pourriez vouloir commencer à chercher est le post de Martin Fowler Mocks Aren't Stubs où il discute beaucoup des idées de moquerie.
dans un paragraphe - Mocking est une technique de particlar pour permettre l'essai d'une unité de code sans dépendre des dépendances. En général, ce qui différencie la moquerie des autres méthodes est que les objets simulés utilisé pour remplacer les dépendances de code permettra de définir des attentes - un objet simulé saura comment il est censé être appelé par votre code et comment répondre.
votre question originale mentionnait TypeMock, donc j'ai laissé ma réponse à cela ci-dessous:
est le nom D'un cadre de moquerie commerciale .
il offre toutes les caractéristiques des cadres de moquerie libre comme RhinoMocks et Moq, plus quelques options plus puissantes.
si vous avez besoin ou non de TypeMock est très discutable - vous pouvez faire la plupart des moqueries que vous voudriez jamais avec les bibliothèques moqueuses libres, et beaucoup soutiennent que les capacités offertes par TypeMock vous éloignera souvent de conception bien encapsulée.
comme l'indiquait une autre réponse, "la typographie" n'est pas en fait un concept défini, mais pourrait être considérée comme le type de moquerie qu'offre la CLR profiler pour intercepter les appels .Net à l'exécution, donnant beaucoup plus de capacité à simuler des objets (pas d'exigences telles que la nécessité d'interfaces ou de méthodes virtuelles).
Simulacre est une méthode/de l'objet qui simule le comportement d'un véritable méthode/objet contrôlée. Les objets simulés sont utilisés dans les essais unitaires.
souvent, une méthode faisant l'objet d'un essai fait appel à d'autres services ou méthodes externes. Celles-ci sont appelées dépendances. Une fois moquées, les dépendances se comportent comme nous les avons définies.
avec les dépendances étant contrôlées par des moqueurs, nous pouvons facilement tester le comportement de la méthode que nous avons codée. C'est Les tests unitaires.
le but des types de moquerie est de couper les dépendances afin d'isoler le test à une unité spécifique. Les talons sont de simples substituts, tandis que les simulacres sont des substituts qui peuvent vérifier l'utilisation. Un framework moqueur est un outil qui vous aidera à générer des talons et des moqueries.
EDIT : depuis que la formulation originale mentionne "type moquerie", j'ai eu l'impression que cela se rapportait à TypeMock. D'après mon expérience, le terme général n'est que "moquerie". Sentez-vous svp libre de ne pas tenir compte des informations ci-dessous spécifiquement sur TypeMock.
L'isolateurTypeMock se distingue de la plupart des autres montures moqueuses par le fait qu'il me permet de modifier IL à la volée. Cela lui permet de simuler des types et des instances que la plupart des autres cadres ne peuvent pas simuler. Pour moquer ces types / instances avec d'autres cadres, vous devez fournir vos propres abstractions et les moquer.
TypeMock offre une grande flexibilité au détriment d'un environnement d'exécution propre. En tant que effet secondaire de la façon dont TypeMock atteint ses résultats vous obtiendrez parfois des résultats très étranges en utilisant TypeMock.
je pense que l'utilisation du cadre de moquerie de L'isolateur de la typographie serait de la typographie.
c'est un outil qui génère des moqueries pour une utilisation dans les tests unitaires, sans avoir besoin d'écrire votre code en pensant au CIO.
Moquerie est la génération pseudo-objets de simuler des objets réels de comportement pour les tests
si votre simulation implique une requête réseau, une autre alternative est d'avoir un vrai serveur de test à activer. Vous pouvez utiliser ce service pour générer une demande et la réponse pour vos tests. http://testerurl.com/