Quelle est la différence entre gtest et gmock?
je suis en train d'essayer de comprendre le but de google-mock,Google C++ se moquant de cadre.
j'ai déjà travaillé avec gtest plus tôt, mais je ne peux toujours pas comprendre ce que gmock est. Pourquoi avons-nous besoin?
gtest est utilisé pour les tests unitaires. Que devons-nous gmock pour ensuite, si gmock est nécessaire pour <!--6?
3 réponses
"Google Mock n'est pas un framework de test lui-même. Au lieu de cela, il a besoin d'un cadre de test pour la rédaction des tests. Google Mock fonctionne parfaitement avec Google Test. Il est livré avec une copie de Google Test empaqueté. A partir de la version 1.1.0, vous pouvez également l'utiliser avec n'importe quel framework de test C++ de votre choix. "Google S'En Moquer, Les Exigences Du Système
Mock sont comme des objets, définis de telle manière à imiter la réalité en fournissant un comportement contrôlé. Par exemple, pour tester une tique de stock application, vous créeriez un faux fournisseur de données boursières qui créerait de fausses cotations boursières pour tester votre code. Penser du mot fantaisie, signifie littéralement "à imiter".
les unités logicielles ne vivent pas à Green meadows. Ils ont très souvent besoin de certains homologues pour faire le travail. Dans le système réel, ces homologues appartiennent au système lui-même. Dans les essais unitaires, ils sont remplacés par des moqueries.
Gtest est un cadre pour les tests unitaires. Gmock est un cadre imitant le reste de votre système lors de tests unitaires.
supposons que vous rédigiez un morceau de code qui doit interagir avec un système externe imprévisible et coûteux (p. ex. un site web, une grande base de données, un capteur physique, etc.) Votre code doit pouvoir continuer à fonctionner lorsque le système externe, ou vous donne des messages d'erreur, ou vous donne des données incohérentes. Comment Pouvez-vous vérifier si votre code satisfait réellement à ces exigences?
Eh bien, vous pouvez l'exécuter contre un site web réel/base de données/capteur / n'importe quoi, un tas de fois, et j'espère que vous la chance dans toutes les conditions d'erreur que votre code est censé gérer. De toute évidence une stratégie de test assez coûteuse et peu fiable.
donc, à la place, vous écrivez quelque chose qui satisfait la même interface que le site Web/base de données/capteur/peu importe, mais que vous avez programmé pour produire certaines réponses "en conserve" (erreurs, temps morts, données incohérentes, etc.) Vos tests seront désormais beaucoup plus rapides (parce qu'ils ne font pas face à la hauteur d'un réel Web site/base de données/capteur/whatever), et qu'ils sont prévisibles. Malheureusement, il faut beaucoup de codage pour rédiger un site web/base de données/capteur/n'importe quoi pour chaque scénario que vous devez tester. Le plus de travail, c'est, moins vous êtes susceptible de le faire. Résultat: code insuffisamment testé.
Gmock et ses parents automatisent beaucoup de ces trucs, de sorte que vous pouvez spécifier le comportement "en conserve" désiré au milieu du test lui-même, au coût de seulement quelques lignes de code. Si les tests sont facile à écrire, vous êtes susceptible d'en écrire plus, et donc plus susceptible de découvrir des bugs avant d'envoyer le code :-)
BTW, cela implique que vous avez aussi besoin d '"injection de dépendances": votre code doit prendre un paramètre du type d'interface, et vous devez être capable de passer soit dans un objet simulé (pour les tests unitaires) ou dans le" vrai " site Web/base de données/capteur/n'importe quoi (pour une utilisation dans le monde réel).