Prologue: Si vous recherchez le nom mock dans le dictionnaire, vous constaterez que l’une des définitions du mot est quelque chose d’imitation.
Le moquage est principalement utilisé dans les tests unitaires. Un objet à tester peut avoir des dépendances sur d'autres objets (complexes). Pour isoler le comportement de l'objet, vous souhaitez remplacer les autres objets par des simulacres simulant le comportement des objets réels. Ceci est utile si les objets réels ne peuvent pas être incorporés au test unitaire.
En bref, se moquer, c'est créer des objets qui simulent le comportement d'objets réels.
Parfois, vous voudrez peut-être distinguer moqueur par opposition à stubbing. Il y a peut-être un certain désaccord sur ce sujet mais ma définition d'un talon est un objet simulé "minimal". Le stub implémente juste assez de comportement pour permettre à l'objet testé d'exécuter le test.
Une maquette est comme une souche, mais le test vérifie également que l'objet testé teste la maquette comme prévu. Une partie du test consiste à vérifier que le modèle a été utilisé correctement.
Pour donner un exemple: Vous pouvez stub une base de données en implémentant une structure simple en mémoire pour stocker des enregistrements. L'objet testé peut ensuite lire et écrire des enregistrements sur le stub de la base de données pour lui permettre d'exécuter le test. Cela pourrait tester certains comportements de l'objet non liés à la base de données et le module de remplacement de base de données serait inclus uniquement pour permettre l'exécution du test.
Si vous souhaitez plutôt vérifier que l'objet testé teste des données spécifiques dans la base de données, vous devrez vous moquer de la base de données. Votre test incorporerait alors des assertions sur ce qui était écrit dans la maquette de base de données.
D'autres réponses expliquent ce que c'est que se moquer. Laissez-moi vous guider avec un exemple . Et croyez-moi, c'est beaucoup plus simple que vous ne le pensez.
tl; dr C'est une sous-classe de la classe d'origine. Il contient d’autres données afin d’éviter de tester les pièces injectées et uniquement focus lors du test du reste du code.
Supposons que vous écrivez une application iOS et que vous ayez des appels réseau. Votre travail consiste à tester votre application. Tester/identifier si les appels réseau fonctionnent ou non comme prévu n'est PAS VOTRE RESPONSABILITÉ. C'est la responsabilité d'une autre partie (équipe de serveurs) de le tester. Vous devez supprimer cette dépendance (réseau) et continuer à tester tout votre code qui fonctionne autour de le.
Un appel réseau peut renvoyer différents codes d'état 404, 500, 200, 303, etc. avec une réponse JSON.
Votre application est supposée fonctionner pour all == (en cas d'erreurs, votre application devrait générer l'erreur attendue). Ce que vous faites avec moqueur est de créer des réponses réseau "imaginaires - similaires aux vraies" (comme un code 200 avec un fichier JSON) et de tester votre code sans 'en passant le véritable appel réseau. et en attente de la réponse de votre réseau '. Vous codez/renvoyez manuellement la réponse réseau pour TOUS les types de réponses réseau et vérifiez si votre application fonctionne comme prévu. (vous jamais == supposez/testez un 200 avec des données incorrectes, car ce n'est pas votre responsabilité, votre responsabilité est de tester votre app avec un correct 200, ou dans le cas d'un 400, 500, vous testez si votre application jette la bonne erreur)
Cette création imaginaire, semblable au réel, est appelée moqueur.
Pour ce faire, vous ne pouvez pas utiliser votre code d'origine (votre code d'origine ne contient pas les réponses pré-insérées, n'est-ce pas?). Vous devez y ajouter quelque chose, injecter/insérer ces données factices qui ne sont normalement pas nécessaires (ou une partie de votre classe).
Ainsi, vous sous-classe la classe d'origine et ajoutez ce que vous voulez (ici, le réseau HTTPResponse, data OR en cas d'échec, vous transmettez la chaîne correcte errorString, HTTPResponse) vous en avez besoin, puis "testez la sous-classe", c’est-à-dire la classe simulée .
Vous ne testez plus la classe d'origine. La maquette/la sous-classe est testée au nom de la classe d'origine
Bref, moqueur veut dire simplify et limit => ce que vous testez et assurez-vous également que vous alimentez ce dont dépend une classe. Dans cet exemple, vous évitez de tester les appels réseau eux-mêmes et plutôt testez si votre application fonctionne comme vous le souhaitez avec les sorties/réponses injectées —— by mocking classes
Inutile de dire que vous testez chaque réponse du réseau séparément.
Maintenant, une question que je me suis toujours posée est la suivante: les contrats/points de terminaison et, fondamentalement, la réponse JSON de mes API sont constamment mis à jour. Comment puis-je écrire des tests unitaires qui tiennent compte de cela?
Pour en savoir plus à ce sujet: supposons que le modèle nécessite une clé/un champ nommé username. Vous testez cela et votre test réussit. Deux semaines plus tard, le système change le nom de la clé en id. Vos tests passent toujours. droite? ou pas?
Est-ce la responsabilité du développeur backend de mettre à jour les modèles? Cela devrait-il faire partie de notre accord de fournir des simulacres mis à jour?
La réponse au problème ci-dessus est que: les tests unitaires + votre processus de développement en tant que développeur côté client devraient/devraient capter une réponse obsolète fausse. Si tu me demandes comment? bien la réponse est:
Notre application réelle échouerait (ou n'échouerait pas encore et n'aurait pas le comportement souhaité) sans utiliser les API mises à jour ... par conséquent, si cela échoue ... nous apporterons des modifications à notre code de développement. Ce qui conduit encore une fois à l’échec de nos tests ... qu’il faudra corriger. (En fait, si nous devons exécuter correctement le processus TDD, nous ne devons écrire aucun code sur le champ à moins d'écrire le test pour celui-ci ... et de le voir échouer, puis d'écrire le code de développement lui-même.)
Tout cela signifie que le back-end n’a pas à dire: "hé, nous avons mis à jour les simulacres" ... il éventuellement passe par votre développement/débogage de code. ّ Parce que tout cela fait partie du processus de développement! Cependant, si le système fournit la réponse simulée pour vous, c'est plus facile.
Tout ce que je veux dire, c’est que (si vous ne pouvez pas automatiser la réponse mise à jour de l’API simulée), une interaction humaine est nécessaire, c’est-à-dire des mises à jour manuelles des fichiers JSON et avoir de courtes réunions pour s'assurer que leurs valeurs sont à jour fera partie de votre processus
Cette section a été écrite grâce à une discussion au sein de notre groupe de rencontres CocoaHead.
Pour les développeurs iOS uniquement:
Ceci est un très bon exemple de moquerie Exposé pratique de Natasha Muraschev sur le protocole Passez à la minute 18h30.
J'aime beaucoup cette partie de la transcription:
Parce que c’est un test ... nous voulons nous assurer que la fonction
getduGettableest appelée, car elle peut retourner et que la fonction pourrait théoriquement affecter une gamme de produits alimentaires de n'importe où . Nous devons nous assurer qu'il s'appelle;
Il y a beaucoup de réponses sur SO et de bons messages sur le Web sur les moqueries. L’un des endroits que vous voudrez peut-être commencer à regarder est le billet de Martin Fowler Mocks Are not Stubs où il discute de nombreuses idées sur le fait de se moquer.
Dans un paragraphe - Mocking est une technique particulière permettant de tester une unité de code sans dépendre de dépendances. En général, ce qui différencie le moquage des autres méthodes, c'est que les objets fictifs utilisés pour remplacer les dépendances de code permettent de définir les attentes. Un objet fictif saura comment il est appelé par votre code et comment répondre.
Votre question initiale mentionnait TypeMock, alors j'ai laissé ma réponse à celle-ci ci-dessous:
TypeMock est le nom d'un cadre commercial moqueur .
Il offre toutes les fonctionnalités des frameworks moqueurs gratuits tels que RhinoMocks et Moq, ainsi que des options plus puissantes.
Que vous ayez besoin ou non de TypeMock est très discutable - vous pouvez vous moquer de tout en vous moquant avec des bibliothèques moqueuses gratuites, et beaucoup soutiennent que les capacités offertes par TypeMock vous éloigneront souvent d'une conception bien encapsulée.
Comme une autre réponse, "TypeMocking" n’est pas réellement un concept défini, mais pourrait signifier le type de moquage offert par TypeMock, en utilisant le profileur CLR pour intercepter les appels .Net au moment de l’exécution, ce qui donne une bien plus grande possibilité de simuler des objets (pas des exigences). besoin d'interfaces ou de méthodes virtuelles).
Mock est une méthode/un objet qui simule le comportement d'une méthode/d'un objet réel de manière contrôlée. Les objets fictifs sont utilisés dans les tests unitaires.
Souvent, une méthode testée appelle d'autres services externes ou méthodes qu'elle contient. Celles-ci s'appellent des dépendances. Une fois moquées, les dépendances se comportent comme nous les avons définies.
Les dépendances étant contrôlées par des simulacres, nous pouvons facilement tester le comportement de la méthode que nous avons codée. Ceci est des tests unitaires.
Le but des types moqueurs est de couper les dépendances afin d’isoler le test d’une unité spécifique. Les talons sont de simples substituts, tandis que les simulacres sont des substituts capables de vérifier l'utilisation. Un framework moqueur est un outil qui vous aidera à générer des moignons et des faux.
EDIT: Depuis que le libellé d'origine mentionne "type moqueur", j'ai eu l'impression qu'il s'agissait de TypeMock. D'après mon expérience, le terme général est simplement "moqueur". S'il vous plaît n'hésitez pas à ignorer les informations ci-dessous spécifiquement sur TypeMock.
TypeMock Isolator diffère de la plupart des autres frameworks moqueurs en ce qu'il fonctionne en modifiant IL à la volée. Cela lui permet de simuler des types et des instances que la plupart des autres frameworks ne peuvent pas simuler. Pour simuler ces types/instances avec d'autres frameworks, vous devez fournir vos propres abstractions et les imiter.
TypeMock offre une grande flexibilité aux dépens d'un environnement d'exécution propre. En tant qu'effet secondaire de la manière dont TypeMock obtient ses résultats, vous obtiendrez parfois des résultats très étranges lorsque vous utiliserez TypeMock.
Mocking génère des pseudo-objets simulant le comportement d'objets réels à des fins de test.
Je penserais que l'utilisation du cadre moqueur d'isolateur TypeMock serait TypeMocking.
C'est un outil qui génère des simulacres à utiliser dans les tests unitaires, sans qu'il soit nécessaire d'écrire votre code avec IoC à l'esprit.
Si votre maquette implique une requête réseau, une autre solution consiste à avoir un serveur de test réel à utiliser. Vous pouvez utiliser ce service pour générer une demande et une réponse pour vos tests. http://testerurl.com/