Mockito : Test d'unité en Java | Programming Made Easy | Skillshare

Vitesse de lecture


1.0x


  • 0.5x
  • 0.75x
  • 1 x (normale)
  • 1.25x
  • 1.5x
  • 1.75x
  • 2x

Mockito : Test d'unité en Java

teacher avatar Programming Made Easy, Software Developer

Regardez ce cours et des milliers d'autres

Bénéficiez d'un accès illimité à tous les cours
Suivez des cours enseignés par des leaders de l'industrie et des professionnels
Explorez divers sujets comme l'illustration, le graphisme, la photographie et bien d'autres

Regardez ce cours et des milliers d'autres

Bénéficiez d'un accès illimité à tous les cours
Suivez des cours enseignés par des leaders de l'industrie et des professionnels
Explorez divers sujets comme l'illustration, le graphisme, la photographie et bien d'autres

Leçons de ce cours

    • 1.

      Bienvenue dans ce cours !

      1:32

    • 2.

      Installation du JDK

      7:16

    • 3.

      Installation Installing IDEA

      3:14

    • 4.

      Qu'est-ce que le moqueur ?

      10:54

    • 5.

      Regardez rapidement un projet Mockito

      6:58

    • 6.

      Configurer votre premier projet Mockito

      16:32

    • 7.

      Spécifier les valeurs de retour

      4:24

    • 8.

      Vérifier le comportement de la méthode

      20:16

    • 9.

      Vérifier la gamme d'appels de méthodes

      8:16

    • 10.

      Le cours InOrder

      5:40

    • 11.

      Matchers d'arguments

      5:12

    • 12.

      Espions

      5:33

  • --
  • Niveau débutant
  • Niveau intermédiaire
  • Niveau avancé
  • Tous niveaux

Généré par la communauté

Le niveau est déterminé par l'opinion majoritaire des apprenants qui ont évalué ce cours. La recommandation de l'enseignant est affichée jusqu'à ce qu'au moins 5 réponses d'apprenants soient collectées.

48

apprenants

--

projet

À propos de ce cours

Bonjour et bienvenue au cours complet sur la dernière itération du cadre Mockito là-bas.

Dans ce cours, nous allons commencer dès zéro et tout d'abord mettre en place notre environnement afin d'écrire du code Java et de tester nos méthodes en utilisant ce cadre.

Je vous présenterai ensuite la théorie derrière le moqueur et les différents types de chaussettes qui existent là. Ainsi, nous pouvons mieux comprendre comment et pourquoi ce processus est-il utile pour nous, non seulement en tant que programmeurs indépendants ou us, mais aussi en constituant un énorme avantage sur votre CV et une chose importante à connaître les idées et les sorties.

En outre, nous allons plonger dans le code en profondeur pour vous permettre de commencer le plus rapidement possible. Je vais utiliser un exemple d'un projet Java simple, mais pratique, pour vous montrer une variété de techniques de moquerie. Vous apprendrez également les meilleures pratiques et les normes de codage pour les tests d'unités en fonction de mon expérience en développement.

Écrire des tests d'unités de grande envergure distingue les bons programmeurs des grands programmeurs. Dans ce cours, vous apprendrez à écrire de grands tests d'unités Java avec Mockito et JUnit.

Selon les statistiques, la plupart des développeurs Java utilisent Mockito lorsqu'ils rédigent des tests pour leurs applications Java. C'est une compétence de base qui est devenue nécessaire, donc si vous souhaitez commencer votre carrière de développeur Java ou la faire passer à un autre niveau, vous devrez écrire des tests unitaires. Avec Mockito, vous les écrirez mieux et plus rapidement.

Donc avec tout cela en étant dit, je pense que vous êtes prêt à commencer à apprendre ce cadre en demande maintenant.

Rencontrez votre enseignant·e

Teacher Profile Image

Programming Made Easy

Software Developer

Enseignant·e
Level: All Levels

Notes attribuées au cours

Les attentes sont-elles satisfaites ?
    Dépassées !
  • 0%
  • Oui
  • 0%
  • En partie
  • 0%
  • Pas vraiment
  • 0%

Pourquoi s'inscrire à Skillshare ?

Suivez des cours Skillshare Original primés

Chaque cours comprend de courtes leçons et des travaux pratiques

Votre abonnement soutient les enseignants Skillshare

Apprenez, où que vous soyez

Suivez des cours où que vous soyez avec l'application Skillshare. Suivez-les en streaming ou téléchargez-les pour les regarder dans l'avion, dans le métro ou tout autre endroit où vous aimez apprendre.

Transcription

1. Bienvenue dans ce cours !: Bonjour les gars et bienvenue dans ce cours sur le framework de test unitaire Java, Mockito. m'appelle elks et je suis ingénieur logiciel qui utilise ce framework dans mon flux de travail de codage depuis utilise ce framework dans un certain temps maintenant, lorsque j'ai entendu parler de la possibilité de créer un cours pour en expliquer davantage sur son utilisation et avantages. J'étais très impatient d'en développer un. Ce cours sera structuré en 11 leçons qui peuvent faire un ping les étapes pratiques à suivre pour comprendre exactement ce qui peut être fait avec Mockito, je vais d'abord vous montrer comment mettre en place un local environnement sur votre machine avec Mockito dessus. Ensuite, nous examinerons de plus près toutes les façons dont ces deux-là facilitent les tests unitaires. Des choses comme le spice, les correspondants d' arguments, les fonctions d'ordre et de vérification, spécifiant les valeurs de retour pour les méthodes, etc. Si vous souhaitez améliorer votre approche des tests unitaires en Java, ce cours est fait pour vous. n'y a pas d'autres conditions préalables qu'un ordinateur doté d'une connexion Internet. Quant au projet de ce cours, il sera extrêmement pratique et il vous faudra suivre les étapes présentées pendant ce cours. Vous pouvez donc commencer votre processus d'écriture de tests unitaires pour le code que vous développez à l'aide de Java. Nous avons pensé, nous l'avons dit, je pense que nous vous voyons déjà dans la première leçon. 2. Installer le JDK: Les gars, bienvenue à nouveau dans ce tutoriel. Dans ce tutoriel, nous allons bien sûr commencer à apprendre en préparant notre environnement sur notre machine locale. Tout d'abord, bien sûr, étant le framework utilisé par le code Java, nous devons nous assurer que le JDK est nous devons nous assurer que installé sur notre machine locale. Le PIB provient donc du SDK Java. Le SDK provient d'un kit de développement logiciel. Pour ce tutoriel. Nous allons utiliser la version d' un point 01 pour Java 16. Tout d'abord, vous devez vous assurer que ces JDK sont installés sur votre ordinateur. Maintenant, j'ai une machine Windows ici. Comment vérifier si ce JDK est déjà installé sur votre ordinateur ou si vous ne l'avez pas, il vous suffit d'exécuter votre CMD. Donc, votre invite de commande avec administration, puis écrivez dans chaque version de tableau de bord Java. Comme vous pouvez le voir, je ne l' ai pas installé. Et ce qui amène sur mon écran, c'est que Java n'est pas reconnu comme une commande interne ou externe, n' est pas installé. Vous pouvez ainsi confirmer que vous ne l' avez pas installé. S'il avait été installé, le message ressemblerait version Java, puis il vous indiquera la version, puis d'autres messages agricoles. Mais maintenant que nous savons que nous ne l' avons pas installé, nous allons le stocker. Si vous l' avez déjà installé, vous pouvez passer à l'étape suivante dans quelques minutes. Mais pour l'instant, comment l' installer serait d'accéder au lien que j'ai fourni sur cet écran ici, et c'est oracle.com, les technologies Java. Java SE télécharge le code HTML. Vous pouvez voir que nous avons ici le travail de téléchargement Java SE, je vois 16. Et nous pouvons cliquer sous le téléchargement Oracle JDK sur JDK. Maintenant, il va nous rediriger vers le kit de développement Java 60. Donc vous voyez le SDK Java, puis en faisant défiler vers le bas, vous pouvez choisir la version votre système d'exploitation, dans mon cas, est un battement de Windows 64, donc c'est la version ici. Je sélectionnerai directement les fichiers exécutables afin que nous puissions passer en revue l'accord, puis cliquer sur Télécharger. Vous pouvez voir que l'exécutable est en cours de téléchargement en ce moment. Dans quelques secondes, cela se fera pour que nous puissions cliquer sur l'ongle. Et comme vous pouvez le voir démarrer cette installation, bienvenue dans l'installation. Nous pouvons cliquer sur Suivant. Maintenant, le bain par défaut où il l'installerait. Et je vous suggère de le laisser SEC est C Program Files, Java, dish, puis la version JDK de celui-ci. La raison pour laquelle je vous dis de le laisser ainsi, c' est parce que nous allons définir plus tard certaines variables de l'environnement. La spécification. Et si vous le modifiez, vous devez vous rappeler que Beth a changé les deux et qu'il peut être basé sur le document Bloc-notes. Mais pour l'instant, nous pouvons simplement continuer et cliquer sur Suivant. Et comme vous pouvez le voir, il commencera essentiellement à installer GDK, qu'il a été complètement installé. Nous pouvons le fermer. Et comme cela, la première étape de ce tutoriel est terminée. La deuxième étape, comme je l'ai dit, nous devons définir une variable d' environnement, plus précisément la variable d'environnement domestique Java. Et nous devons le pointer vers le bain où nous arrêtons ces JDK. Pour ce faire, vous devez accéder au bouton Rechercher, puis écrire les variables d' environnement système. Cliquez sur Entrée. Ensuite, voici les variables d' environnement. Ensuite, nous pouvons cliquer sur Nouveau. Ensuite, nous avons le nom de la variable, qui sera Java sous la maison, puis le répertoire de navigation. Et puis le répertoire va à BSA a dit Local Disk C Program Files, puis bien sûr Java, et ensuite ce JDK pour la dette, il nous a eu. Donc, tout va bien se passer. Et comme vous pouvez le voir ici, la variable du système domestique Java est maintenant ajoutée et sa valeur est la vraie Beth. Maintenant, nous pouvons en outre ajouter la variable système de Java home avec la valeur du chemin ici à bat, nous devons modifier cela et ajouter un nouveau. Et ensuite, nous avons besoin de graphiques pour la dette du dossier bin avec modification ici. Et puis, comme vous pouvez le voir, le JDK Java et ce dossier d'être ici juste après mon arrivée, ont démarré mon ordinateur. Parce que si vous ne le redémarrez pas, vous ne pourrez pas voir que Java est installé lorsque vous le redémarrez et entrez la version de Java Dash, vous pouvez voir qu'il vous donne des informations sur les attributs et plus particulièrement le fait que le JDK s' est installé correctement sur votre ordinateur. Une fois de plus, j'ai ajouté les variables système de la maison de soulignement Java au chemin d'accès où le GDK a été installé et j'ai ajouté à l'arrière. Donc, les variables utilisateur pour votre utilisateur, puis vous cliquez dessus, cliquez sur Modifier, puis sur le nouveau navigateur, puis sur le dossier bin de l'installation de JDK souffle. Si vous le faites après avoir installé le JDK que vous obtenez à partir de ce lien, vous allez installer le JDK sur votre ordinateur et effectuer les deux premières étapes. Pour l'instant. Il s'agissait de l'entrée. Je vous remercie beaucoup de rester avec moi jusqu'à la fin de cette conférence. 3. Installer une idée Installing: Bonjour les gars et bienvenue dans le tutoriel. Pour ce tutoriel, nous devons évidemment disposer d'un IDE dans lequel nous pouvons sauter du code. Et pour cela, nous allons utiliser l'IDE IntelliJ IDE, qui, selon moi, est le meilleur IDE pour Java. Mais nous pouvons commencer à grandir pour intelligent, puis cliquer sur le site Web Télécharger sur JetBrains. Cela vous redirigera vers le téléchargement d'Intel G. Idea. Bien sûr, nous allons maintenant utiliser la version communautaire. L'ultime n'est pas de ne pas écrire de code pour l'entreprise informatique. Nous allons simplement les utiliser dans le confort de nos propres maisons. Mais si vous voulez le faire par tous les moyens, si vous avez une entreprise ou quelque chose du genre, vous pouvez opter pour l'ultime. C'est juste que pour ce tutoriel, nous allons utiliser le point Windows EXE. Et comme vous pouvez le voir, le téléchargement a commencé. Je reviendrai vers vous une fois que c'est fini. Ok, donc je suis de retour qu'Intel a été téléchargé des perles et maintenant, lorsque nous cliquons sur ce fichier exécutable, nous allons être accueillis par un processus d'installation. Vous pouvez voir le week-end de configuration se poursuivre dans l'installation. Il utilise notre dossier de destination par défaut dans le lecteur C. Maintenant, la longitude 64 bits est ce que vous allez devoir sélectionner ici. Ensuite, nous allons associer les fichiers Java à celui-ci. Ensuite, nous pouvons mettre à jour le menu contextuel, modifier le projet Ouvrir le dossier est. Les répertoires des lanceurs sur le lit. Je ne pense pas que ce soit nécessaire, c'est que nous ouvrirons les choses à partir de l'application réelle afin que nous puissions continuer à cliquer sur Suivant, puis l'installer. Une fois qu'il aura été installé, vous serez accueilli avec cette dernière fenêtre. Et vous pouvez choisir d'exécuter Intel J une fois l'installation terminée et nous pouvons cliquer sur la dette. Nous avons confirmé que nous avons lu et cliqué sur Continuer. Vous pouvez voir que l'Intel G ID va s'ouvrir maintenant. Et il nous demandera d'ouvrir un projet ou d'en créer un nouveau. Et puis, bien sûr, quelques plug-ins dans la fenêtre de personnalisation concernant les thèmes de couleurs et autres choses comme ça. Il s'agissait donc de l'installation de GID pour le travail que nous allons utiliser dans ce tutoriel. C'est un WordPress assez simple et direct, mais j'ai pensé que je devrais faire le tutoriel sur ceux-ci juste pour m'assurer que vous êtes conscients de la façon dont vous allez mettre en place. J'espère que vous avez obtenu quelque chose de ce tutoriel, et j'ai vraiment hâte de vous voir dans le prochain. Merci beaucoup de rester avec moi jusqu'à la fin de cette conférence. 4. Qu'est-ce que la maquette ?: Bonjour les gars et bienvenue dans ce tutoriel Mockito où nous comprenons comment nous pouvons mieux face nos méthodes Java en utilisant ce framework de test. Dans cette conférence, nous allons jeter un coup d'œil à quelques notions théoriques sur la moquerie. Juste avant de nous plonger en profondeur dans le cadre de tests Mockito et de comprendre comment écrire du code pour tester nos méthodes. Nous allons couvrir quelques éléments de base comme ce qui se moque, ce qui doit être marqué, différents types de marques et ce genre de choses. Juste pour que nous puissions en avoir une bonne connaissance avant de l'appliquer. Nous comprenons le processus que nous allons suivre pour écrire le code réel dans nos identifiants. En termes simples, le processus de marquage fait référence à fournir un contrôle, instance ou une implémentation, voire une dépendance dont dépend le code testé. Afin de tester chaque logique de base. Dans le cas de notre première application Mockito, la chaise va examiner dans la prochaine conférence de la section avant d'entrer dans les détails plus détaillés de Mockito, je vais vous présenter une base application utilisant Mockito et dans une demande de créance. La méthode qui sera référencée dans une fonction que nous voulons tester sera moquée et on demandera de renvoyer une valeur spécifique que nous désirons. C'est donc la pratique du marquage. Ces marques viennent à la rescousse dans les situations où peu importe que votre dépendance soit en hausse et que vous vous entraîniez ou non, vous êtes toujours assuré de gérer votre logique métier avec une réponse programmée pour la dépendance appelée à partir du code en cours de test. Si vous avez déjà entendu le troisième double test se réfère essentiellement à un objet qui est remplacé par une arborescence ou une instance d'objet équivalente ou une dépendance. Il y a deux principaux avantages quant à la raison pour laquelle les processus de moquerie sont utiles lors du test de notre code. Vous pouvez les considérer comme les piliers de base sur lesquels nous fondons l'utilisation de nos tests unitaires. Le premier avantage est l'efficacité que le processus de fumage apporte avec lui. Parce qu'en se moquant, nous sommes assurés qu'il n'y a que notre code qui est exécuté. En cas de test. Toutes les autres dépendances auront des valeurs codées en dur et moquées fournies par nous et ce code ne sera pas réellement exécuté. Maintenant, l'autre raison est le contrôle exact que nous avons sur tous les autres composants dont notre fonction test IF a besoin. Cela peut créer une séparation très bénéfique. aidant ainsi à voir rapidement si la fonction que nous voulons tester se comporte AES-128 ou non comme les pièces utilisées dans le processus qui ne font pas réellement partie de la fonction que nous voulons. test. Nous aurons des valeurs définies qui seront marquées par nous. Nous saurons déjà quel est le retour et comment ils se comportent. Et nous ne faisons que limiter nos tests. La fonction que nous voulions réellement tester. Il existe différents types de doubles ou de repères de test. Et nous allons passer en revue chacun d'entre eux juste pour que vous puissiez mieux comprendre leur classement. Et dans une conférence future, si vous voyez l'un de ces noms, vous serez familiarisé avec lui et vous comprendrez rapidement et aurez un point de référence quant au type exact de ce double E. Tout d'abord, nous avons les faux. Les faux fonctionnent une implémentation assez similaire à une vraie dépendance, sauf le fait qu' elle se trouve sur la machine locale où le code testé reste réellement. Ici, l'exemple le plus souvent utilisé et le scénario que nous sommes faux sont les plus utiles. Quand il s'agit de la persistance de Thêta. Lorsque vous traitez des bases de données. Et au lieu d'installer une véritable base de données de production, test utilise une collection simple ou en mémoire pour stocker des données. Et pourquoi cela est très utile, c'est parce que vous ne voudrez peut-être pas de données de production réelle pour chaque test que vous effectuez remplir certaines lignes dans la base de données de production réelle pour chaque test que vous effectuez. Ou même vous disposez d'une base de données de test. Peut-être ne voulez-vous pas le peupler parce qu' il peut y avoir des problèmes lorsque nous le faisons. Le premier serait que Daniel doit le supprimer. deuxième serait le temps et l' efficacité gaspillés dans ces deux opérations. Même pour dire que base de données n'a même pas de profondeur que vous souhaitez tester. Nous voulons tester une méthode qui appelle la base de données réelle. Vous vouliez voir comment se comporte la fonction et non si l'appel à la base de données fonctionne réellement, cela devrait être dans une autre classe. Si vous avez une bonne séparation dans votre projet. Et cette classe devrait être dans le projet de référentiels, où le personnel concernant la base de données est encore modifié. Quels faux sont utilisés la plupart du temps. Ils sont très importants de ce point de vue. Ensuite, nous avons les talons. Et ces éléments ne sont que des réponses préconfigurées lorsqu' une dépendance est appelée à partir du système que ces 100 tests. Maintenant, à part les arrêts, nous avons aussi Spice. Ils sont différents des arrêts, faux et des marques car la fonction réelle ou la dépendance est réellement appelée. En épice. Il a un mécanisme de surveillance qui est attaché à cet appel pour test Delta B et publie l' appel ce mécanisme de surveillance. Il est possible de vérifier si le charbon a été réellement déclenché ou non avec les paramètres. Enfin, nous avons le type de double test le plus important lequel nous allons concentrer sur lequel nous allons concentrer la majorité de ce cours. C'est ça les mocks. Les repères sont des instances spéciales d'objets et les réponses des sujets peuvent être spécifiées par le testeur. C'est ce qui les rend uniques. Le fait que l' intestin Mach appelé peut être vérifié l' assertion SAML dans le test. Et ce sera l'angle dans lequel nous brillerons Mockito, comme vous le verrez dans le projet d'aperçu dont je parle. Et nous y reviendrons dans un instant au cours de la prochaine conférence. Il facilite la création de faux objets en toute transparence. ce faire, il faut utiliser la fonction de réflexion sur Java afin de créer des objets simulés pour une interface donnée. Vous avez donc une interface qui crée essentiellement un objet instancié en tant que concret. Mais ce béton n'existe pas vraiment. Il suffit de le marquer jusqu'à ce que vous l'inventiez et de lui faire renvoyer certaines valeurs que vous pensez en ligne et qui vous intéressent afin les valeurs de la dette apparaissent dans la fonction que vous souhaitez réellement tester. . Et de plus, pour voir à nouveau comment la fonction se comporte lorsqu'elle a contrôlé les paramètres d'entrée étant donné I, soit en tant que paramètres que résultats des fonctions appelées Long image. Maintenant, quelques mots pour expliquer pourquoi Moche W si populaire et que vous devriez choisir d'étudier, c'est que ce framework vous permet de créer et de configurer ces objets simulés dont nous avons parlé. Cela serait très évident d'après le titre de ce cadre également. Mais l'utilisation de Mockito simplifie grandement le développement des tests que vous effectuez pour des classes avec des dépendances externes ou des méthodes simples au sein de ces classes. Si vous, le framework de statistiques de test, vous pouvez, comme je l'ai dit, vous moquer des dépendances externes et également insérer les repères dans le code sous test. Dose que vous souhaitez attribuer ces valeurs spécifiques aux fonctions de la fonction que vous souhaitez tester afin de voir comment elle se comporte. Vous pouvez bien sûr exécuter le code en cours de test avec singe DO et valider que le code est exécuté correctement dans cet environnement contrôlé que vous avez configuré avec le processus de marquage. Il s'agissait de manger pour les notions moquantes théoriques que vous tirez, que vous avez en place juste avant que nous commencions la moquerie réelle dans le code et voyons comment cela fonctionne. Par conséquent, non. Dans la prochaine conférence, nous allons voir un aperçu rapide du premier projet Mockito que j'aurai mis place à l'aide du résolveur de dépendances gravier. Et si cela vous semble intéressant, j'ai hâte de vous voir lors de la prochaine conférence. Et je remercie beaucoup être resté avec moi jusqu'à la fin de celle-ci. 5. Aperçu rapide d'un projet Mockito: Bonjour les gars et bienvenue dans ce tutoriel Mockito où nous comprenons comment mieux tester nos méthodes de chatbot l'aide de ce framework de test unitaire. Pour cette conférence, nous allons jeter un coup d'œil sur la façon dont nous pouvons mettre en place notre projet à New Delhi afin que nous puissions rédiger tests unitaires qui utilisent principalement le framework Mockito. Une fois que vous ouvrez IntelliJ, vous pouvez cliquer sur Nouveau projet pour que vous ayez évidemment assez de grec, un nouveau projet. Ensuite, dans cette fenêtre que vous voyez à l'écran , vous devez sélectionner Gretel. Ensuite, vous devez cocher Java et le SDK de Java que vous avez téléchargé sur votre machine locale. J'ai déjà eu une conférence maintenant, vous pouvez le faire. Mais si vous l'avez déjà installé, vous pouvez bien sûr ajouter JDK. Alors clignez le chemin que vous avez sur votre machine locale ou vous pouvez télécharger directement le TFUE n'a pas suivi cette étape de téléchargement de votre GDK directement à partir de l' intelligent, mais nous l'avons obtenu. Nous pouvons donc cliquer sur Suivant. Voici le nom de notre projet. Je vais nommer mon projet ou mon tutoriel. Et l'emplacement sera celui par défaut situé dans le dossier Idea Projects. Ensuite, l'ID de l'artefact va battre le tutoriel, l'ID de groupe ou les exemples de points ORT. C'est assez simple. Et lorsque vous cliquez sur Terminer, pour sélectionner la nouvelle fenêtre, j'ai déjà eu une fenêtre ouverte avec un autre projet. Maintenant, vous pouvez voir que nous avons ouvert un projet de base et qu'il est presque prêt à écrire du code. Et vous pouvez voir que lorsqu'il s'ouvrira, Gretel va construire l'initiation. Juste pour voir que tout va bien et que tout va bien. Vous pouvez voir que la construction a été couronnée de succès. Et ici, sur la bonne partie, nous avons également un excellent robinet d'orteil sans avoir à construire, assembler, construire et toutes ces bonnes choses. Et vous pouvez exécuter chacun d'entre eux afin que vous puissiez dire que tout va bien, mais tout devrait être en ordre dans votre environnement si vous suivez les étapes que je viens de décrire dans les cours. Donc, la première chose que vous allez devoir faire pour que Mockito fonctionne, c'est d'aller dans ce dossier de facture à ce Gretel, ici, dans la fenêtre du projet qui s' ouvre en haut et sur dans la section dépendances de la ligne 12, vous devrez entrer ces deux lignes. Alors testez la mise en œuvre de notre jeep. Ce Mockito, Mockito sur la ligne 377 et Mockito, vous avez besoin de Jupiter 377. Une fois que vous entrez ces deux valeurs, vous pouvez voir que vous avez cet éléphant. Il dispose également d'un signe de sessions synchrone en bas à droite. Et si vous survolez dessus, vous pouvez voir que cela signifie que vous pouvez autoriser les changements graduels. Et il détecte essentiellement que la structure du projet a changé. Et pour que ces changements soient assimilés dans le système, qu'ils puissent s'en inspirer et résoudre toutes les références, vous devez charger ces modifications graduelles. Une fois que vous avez cliqué dessus, vous pouvez obtenir une autre version. Et une fois que cela a été fait, vous pouvez continuer à écrire votre code. Le code va être placé dans ces deux dossiers. Vous avez le dossier principal avec le sous-dossier Java dans lequel vous allez placer le lieu de travail, ces interfaces, etc. Donc, en gros, c'est le code qui va être testé. Le code de sortie. Donc, pour le nommer dans le dossier de test, plus précisément encore une fois, dans le travail un sous-dossier, vous allez créer des classes de test. Les classes vont utiliser Mockito afin de tester les méthodes des classes disponibles et écrites par vous que vous souhaitez tester dans le dossier Java du dossier parent principal. Et bien sûr, vous pouvez simplement continuer après cette configuration de base pour mûrir votre test unitaire Mockito. Bien sûr, il faut importer Mockito, mais ce n'est qu'une ligne de code. Plus précisément, il est important d'importer l'ORT statique que Mockito point Mockito avec une majuscule M puis une étoile de point afin qu'il puisse récupérer l'ensemble d'une bibliothèque. Et ensuite, vous pouvez utiliser toutes les bonnes choses comme les méthodes de Mach quand et ainsi de suite. Nous allons bien sûr entrer dans les prochaines conférences. Mais c'était au-dessus de cela. Maintenant, si vous ne voyez pas que votre solution Gradle simple se construit comme dans mon cas, elle a été automatiquement construite. Ce que vous devez faire, c'est de cliquer sur cette grille bleue, puis de cliquer dessus avec le bouton droit de la souris , puis d'exécuter le didacticiel. Et cela sera par défaut, exécution est construite sur l'ensemble du projet. Bien sûr, il l' exécutera avec toutes les dépendances que vous entrez ici. C'était un environnement de base que vous devez configurer sur votre machine locale avant d'aller plus loin, ce tutoriel, si vous le souhaitez, a en fait une bonne expérience. Donc, si vous voulez reproduire ce que je fais ou que je le fais à votre manière ou d'une manière similaire, car cela commence par les dépendances et c'est ainsi que vous devez configurer votre projet Intel J. Mais c'était à peu près tout cela pour cette conférence. J'ai hâte de vous voir dans les prochains, où nous allons prendre quelques mots-clés, notions et choses que notions et choses que le framework Mockito et faire plus en détail, comprendre et y plonger en profondeur. Cela semble intéressant. J'ai hâte de vous y voir. Et encore une fois, je vous remercie beaucoup resté avec moi jusqu'à la fin de cette conférence. 6. Configuration de votre premier projet de Mockito: Bonjour les gars, et bienvenue dans ce tutoriel Mockito, Java Framework, où nous comprenons mieux comment tester nos méthodes Java à l'aide de ce framework de test. Car, pour cette conférence, nous allons examiner la première application que nous avons, quelques-uns des concepts que nous allons approfondir plus loin dans ce tutoriel. Juste pour vous de faire une image de l' apparence d'un projet dans chaque ensemble. Et aussi comment créeriez-vous le départ à partir de 0 ? Pour commencer, nous allons bien sûr nous diriger vers le MII que nous avons choisi pour Java. C'est IntelliJ J, comme vous l'avez vu lors des dernières conférences. Dans vous allez bien sûr créer un nouveau projet. Et vous pouvez soit aller déposer un nouveau projet , soit si vous n'avez pas déjà de projet ouvert, il n'ouvrira rien d'autre que la fenêtre de démarrage où vous vous redirigez vers ouverture d'un projet ou d'un nouveau projet. Vous pouvez configurer un nouveau projet et ce que vous souhaitez sélectionner Suivant est progressif. Au lieu de Java simple. La raison en est que cela facilite grandement notre travail lorsque nous relions le cadre Mockito dans notre projet. Donc, au lieu de simplement télécharger les fichiers GIA IR à partir des référentiels Maven, le fichier JAR de jambon, le Mockito, et également de lier les variables système DOS à l'arrière. Ce que cela va faire. Niveleuse reliera automatiquement Mockito très facilement, comme je vous le montrerai dans une seconde à notre projet. Nous allons donc utiliser la grille off pour ce tutoriel. Au cas où vous ne le sauriez pas, je vais vous expliquer rapidement quel crédit. Vous pouvez donc penser à un outil d'automatisation. Ce qu'il fait, c'est automatiser la création d'applications, rend beaucoup plus facile et plus rapide. Il s'agit de l'automatisation qui inclut le lien dans emballage et la compilation de différentes parties de votre code. Mais pour l'instant, vous pouvez simplement choisir Gretel ici sur la densité de projet j, vous avez besoin. Bien sûr, choisissez JDK que vous avez installé. Sur votre machine locale. Nous avons installé notre dette de 16 JDK est automatiquement détectée par intelligente car nous l'avons laissée à son propre chemin par défaut. Mais si vous avez choisi ce chemin d'une manière différente ou si vous avez installé une version différente de JDK, il devrait être automatiquement, comme je l'ai dit, être choisi ici. Mais si ce n'est pas le cas, vous pouvez soit télécharger JDK si vous ne l'avez pas et il sera automatiquement téléchargé pour vous. Vous n'avez pas besoin de suivre tout ce processus depuis la conférence précédente. Vous pouvez également ajouter votre JDK si vous l'avez déjà installé, mais il n'est pas détecté. Vous pouvez choisir le chemin d'accès où vous installez ce fichier bin. Mais pour l'instant, vous pouvez également choisir Java , puis cliquer sur le nom du projet et de l'emplacement. De plus, les coordonnées de l'artefact en tant qu'ID d'artefact sont entièrement à votre charge. Ce n'est donc en aucun cas notre projet. Ensuite, lorsque vous cliquez sur Terminer, un projet s'ouvre pour vous par défaut à partir de la largeur inférieure non incluse. Bien sûr, nous allons le faire dans une prochaine conférence et je vous expliquerai exactement comment les dépendances sont construites et ce que vous devez faire pour importer Mockito et toutes ces bonnes choses. Mais cette conférence a juste pour but de vous montrer un projet rapide que j'ai mis place ici même avec des cours qui fonctionnent réellement avec le framework Mockito. Afin de tester une méthode spécifique d'une classe spécifique, nous allons jeter un coup d'œil juste pour vous faire une meilleure idée du fonctionnement des choses dans ce cadre de test unique. Vous pouvez voir ici que j'ai un fichier industriel, le fichier principal. Ici, j'ai un Java. Un fichier, bien sûr, avec le fichier principal, nous avons le fichier test où, intuitivement, nous allons écrire nos méthodes de test. Dans le Java. Nous allons simplement déclarer nos cours. Types de méthodes que nous voudrions peut-être être testées. Pour commencer, nous avons la vitre de voiture ici. Cette classe comporte trois champs, ID de voiture, c' est-à-dire une chaîne, un nom, une chaîne et une quantité qui est une chaîne. Et nous imaginons ces exercices comme une sorte d'autorité qui vend bien des voitures, je l'ai appelé le concessionnaire. Nous disposons également d'un service de voiture qui facilite ces transferts. Maintenant, une autre observation ici est que lorsque vous entendez que cette classe a du service en son nom, vous devriez automatiquement penser que cette classe fait certaines méthodes pour vos autres classes. Nous y avons été un service américain. Et si vous entendez que le référentiel a quelque chose à voir avec la persistance de bonnes données, stocker dans une base de données, etc. C'était juste une parenthèse rapide. Alors maintenant, la voiture de classe a bien sûr un constructeur avec les trois paramètres qui ont été initialisés ici. Ensuite, nous recevons des setters et des getters publics. Et grâce à cela, nous allons réellement définir ou faire nos champs privés atteignent ainsi. Encapsulation faite, bonne pratique. C'est la liste, rien de vraiment hors de l'ordinaire ici. Juste quelques champs qui se fixent et obtiennent la paroi cellulaire. Nous ne pouvons vraiment rien tester ici, mais nous allons voir que nous ne faisons que des tests ou des cours faciles à faire. Eh bien, soyez plus loin ici maintenant, nous avons aussi des concessionnaires automobiles. C'est donc la méthode que nous allons tester la cellule de verre. Tout d'abord, nous importons Java util Beast car nous allons utiliser la liste ici à la ligne 15. Mais le concessionnaire automobile de classe doit filtrer. Vous en avez besoin d'un service automobile, qui est une interface et une carte des vins de voitures, car le concessionnaire aurait au moins des voitures, bien sûr. Maintenant, le service automobile devient meilleur et aussi un passeur. Et puis la liste des voitures est également dans le getter. Enfin, nous avons ici une autre méthode qui va être testée en utilisant le cas du framework. Vous verrez dans un instant, ce qu'il fait, c'est qu'elle déclare une variable de type double appelée valeur marchande, et elle l'incrémente de 0. Maintenant, nous allons dire aux voitures le moins qu'il soit membre de cette classe. Nous allons augmenter le prix d'achat d'une voiture. Ainsi, les services automobiles peuvent voir que c'est juste une interface qui a la signature de get price ici. Et c'est la méthode que nous allons nous moquer en utilisant Mockito pour retourner quelque chose que nous voulions. C'est ce que Mark veut dire. Et à part cela, nous allons multiplier le prix que nous allons marquer la valeur que nous allons donner. La méthode de quantité qui, bien sûr, appartient à la catégorie des voitures. La quantité qui renvoie le nombre de voitures qu'il y a. Enfin, après avoir parcouru chaque voiture et l' avoir incrémentée avec cette valeur de multiplication, nous allons renvoyer cette valeur. Comme je l'ai dit, le service automobile a cette signature, une méthode qui n'est pas réellement implémentée. Et nous allons maintenant passer à la classe de test. Comme vous pouvez le voir sous test et Java, cette façon, nous ne savons pas s' il s'agit de la méthode de test. Voici la magie qui se produit, pour ainsi dire, et Mockito est impliqué. C'est la classe des tests de cartes que nous allons simplement importer des utilitaires que nous allons utiliser. Ainsi, vous pouvez voir que nous importons le Mockito. Comme je l'ai dit lors d'une prochaine conférence, nous allons voir exactement comment importer ces Mockito à l'aide de Gretel. Nous commençons à faire partie de la classe des testeurs de cartes ici. Nous avons donc un concessionnaire automobile, le service automobile. Le service est une interface. Ici, nous avons la méthode principale qui est le point d'entrée où nous allons les exécuter, c' est assez simple. Nous déclarons un testeur de carte, qui est cette classe. Nous allons donc l' instancier et ensuite vous allez l'appeler configuration pour cela. La configuration est donc cette méthode ici qui instancie le concessionnaire et le service automobile. peux voir pour le service automobile que ce n'est qu' une interface que j'ai dit dans laquelle je n'ai pas réellement implémenté. Nous allons utiliser la méthode simulée de Mockito. Et nous allons vous donner le service de voiture et la vitre. Nous allons donc simplement marquer la classe car il s' agira d'une classe concrète non pas seulement d'une interface pour le concessionnaire. Nous allons également régler le service automobile sur ces services automobiles marqués, comme vous pouvez le voir ici dans méthode principale après avoir configuré ces tests, leur objet de test de carte de type, nous sommes va coder cette valeur marchande de test. Et selon le booléen et il revient, nous allons manger le mieux encadré si le test réussit ou échoue. S'il échoue. En approfondissant cette valeur marchande de test, une méthode. Ici, nous allons juste déclarer une liste de voitures. Ensuite, je vais instancier deux objets de type car. Le premier est Lamborghini et le second étant une Audi. Utiliser le constructeur avec toutes les valeurs réelles. Nous allons leur donner un numéro de stock, des noms et les quantités que nous devons apprendre à bien fonctionner. Et trois sont ces deux voitures, qui sont en fait des listes de voitures parce qu'elles vont commencer à utiliser ces trois voitures ou elles vont être ajoutées à notre liste, bien sûr, qu' on appelle les voitures comme vous pouvez le voir en ligne jusqu'en 1637. Ensuite, le 40, nous allons appeler la méthode sur l'objet du concessionnaire. C'est un concessionnaire automobile. La méthode de ces cartes de jeu a été, si vous vous souvenez d'ajuster l' attribution de la liste que nous lui donnons en tant que paramètre à la liste des champs au concessionnaire automobile. De plus, après cela, c'est ici que la scène demo.com et bien sûr, nous aurons une conférence ultérieure où j' expliquerai exactement ce que fait cette méthode. Mais pour l'instant, juste pour que vous puissiez obtenir une vue d'ensemble, quelle est cette méthode quand on reçoit essentiellement un appel. Il dit quand la méthode des prix de l' écart du service du Christ serait appelée avec un paramètre de Lamborghini. Ensuite, vous devriez lire 250 000, ce qui serait le prix de Lamborghini que j'ai estimé. Et encore une fois, quand ils obtiennent le prix, la méthode de service automobile serait appelée en utilisant la voiture, alors vous devriez retourner 50 000. Encore une fois, il marque ces appels. Donc, le code n'a pas à passer par toutes les classes de prix, car vous voudrez simplement tester la méthode de la valeur marchande. Et c'est ce qu'il fait. Il marque le verre de la méthode d'obtention de Bryce. Et après les avoir vus, vous pouvez voir que nous allons appeler la fonction d' obtention de la valeur marchande à partir du verre du concessionnaire, qui était celui-ci. Et comme vous pouvez le voir ici, nous marquons la méthode du prix net car ce n'est pas ce que nous voulons tester. Nous voulons simplement que cela obtienne la méthode de la valeur marchande. Et comme je l'ai dit, quand on l'appellerait, il irait dans les voitures et tout d'abord, il le livrera au numéro des guinées. Et quand le service automobile obtiendra prix de Lamborghini serait appelé, le Mockito vous dit de revenir à 50 000 et même de ne pas prendre la peine d'appeler le prix réel, ce qui, bien sûr, n'est même pas implémenté car il s'agit d'une interface et nous la marquons. Ensuite, toute l'ADI de la même manière et la bête nous permet de tester la méthode d'obtenir de la valeur marchande dans conditions très contrôlées et aussi très efficacement car ils obtiennent la méthode du prix ne va pas au froid et al. Comme je l'ai dit, nous allons appeler cela du concessionnaire. Après cela, nous allons tourner la valeur marchande égale à 650 000, ce qui serait la valeur correcte étant donné que 250 000 fois deux sont 525 000 000 fois 350 000. Ajoutez ces deux-là et vous en obtiendrez 650 000. Bien sûr, il va maintenant imprimer soit réussir, soit échouer, en fonction de ces valeurs vraies ou non, la valeur que cette valeur de marché de test retourne. Donc, si nous cliquons avec le bouton droit sur la classe de testeur de voiture, nous disons le domaine Ron Cortez. Vous pouvez voir qu'en ce moment, l'ensemble du projet est en train de développer et d'intéresser tout le projet. Deuxièmement, vous pouvez voir que c'est un meilleur. Voyons maintenant si cela fonctionne. Si nous en avions 65 000, ce qui n'est pas la bonne valeur, vous devriez échouer ici. Voyons donc si cela se produit. Cela arrive. Maintenant, il s'agissait de l'acte de la première introduction sur Mockito. voyant un projet plus important en ville, Mockito s'habituerait à un projet déjà mis en place. Mais à partir de la prochaine conférence, nous allons progressivement présenter dès le début comment créer votre premier projet. Présentez également des mots-clés et des caractéristiques spécifiques du framework Mockito et comment ils sont utilisés, ce qu'ils font, etc. Donc, si cela vous semble intéressant, j'espère que je vous verrai là-bas. Et merci beaucoup de rester avec moi jusqu'à la fin de ce tutoriel. 7. Spécifier les valeurs de retour: Bonjour les gars et bienvenue dans ce tutoriel Mockito où nous comprenons mieux comment tester nos méthodes en Java à l'aide de ce framework de test unitaire. Dans cette conférence, nous allons examiner comment Mockito peut spécifier des valeurs de retour dans différents scénarios pour certaines fonctions appelées dans différents types de situations. Avec Mockito, vous pouvez ajouter des fonctionnalités permettant de marquer un objet à l'aide de différentes méthodes. Vous pouvez voir que c'est ce que nous avons fait ici, sur notre bureau, à la ligne 23. Nous avons marqué toute la classe de service automobile qui se trouvait sur une interface et nous n'avons eu aucune implémentation réelle. Mais à part ce rein Mockito, il peut également marquer le comportement d' une fonction appelée avec certains paramètres. Et lors du marquage de la dette, il peut spécifier la valeur de rendement exacte que cette fonction doit avoir lorsqu'elle est appelée avec ce paramètre spécifique. Par exemple, en ligne 43. Comme vous pouvez le voir, le Mockito a demandé la fonction d'obtenir le prix du service automobile, qui n'avait en fait aucune implémentation dans l'interface. Pour rendre les 250 mille vous échouer quand vous refroidissez, nous pourrions l'argument de Lamborghini. Et comme vous pouvez le voir, la syntaxe empilée pour cela est le mot-clé wing. Ensuite, la fonction qui va être appelée avec un paramètre spécifique. dette est donc la situation dans laquelle vous souhaitez ajouter ce comportement. Et puis le mot-clé den return, puis la valeur, la fonction qui est appelée avec paramètre spécifique devrait avoir dans la situation exacte de la dette. À ce moment-là. Mock a déjà enregistré le comportement et il fonctionne un objet simulé, type d'interface de service automobile. L'objet de service automobile est déjà un objet simulé. Encore une fois, je l'ai déjà dit, ce code ici est très utile car ce code sera exécuté chez le concessionnaire, obtiendra de la valeur marchande. Nous allons tester et nous voulons que ces deux appels aient nos valeurs exactes données, valeurs marquées, juste pour nous assurer que cette fonction se déroule bien ou non concernant cette fonction de get. prix. Donc, que la fonction de get price fonctionne ou non, méthode définie deux fois, car nous spécifions les valeurs qu'elle doit renvoyer. Et nous voulons nous concentrer sur les tests unitaires pour obtenir une méthode de valeur marchande. C'est la méthode de base de quand puis retour, qui est SHE dit, le framework Mockito spécifiant les valeurs de retour. Comme certains autres programmeurs pourraient penser. Il s'agit d'ajouter le comportement. Dans certains types de situations. C'est une chose assez utile lorsque vous voulez créer cette séparation dont nous avons parlé de la classe que vous souhaitez tester dans la sous-dépendance et les classes qui y sont appelées. C'était donc au-dessus de l'acte de cette conférence. Et dans le prochain, nous allons commencer à examiner le mot-clé vérifié, qui est un mot-clé très important, démo dope, framework de test unitaire. Et nous allons voir exactement ce que cela fait et tous les différents scénarios qui sont nombreux vérifient que le mot-clé peut être utilisé. Cela semble intéressant. J'ai hâte de vous y voir et vous remercie beaucoup de rester avec moi jusqu'à la fin de cette conférence. 8. Vérifier le comportement de la méthode: Bonjour les gars et bienvenue dans le fumé dit à Turiel. Où que nous comprenions comment nous pouvons mieux tester nos méthodes écrites en Java à l'aide de ce framework. Dans cette conférence, nous allons parler de la méthode de vérification que Mockito nous fournit. Aussi comment nous pouvons l'utiliser et pourquoi utile pour nous lorsque nous essayons d'unifier cette ou même plusieurs méthodes que nous avons écrites dans le R. Peut-être en production ou peut-être voudrions-nous les déployer à un moment donné dans le futur. Pour commencer ici, j'ai créé un tout nouveau projet dans Intel J. et la façon dont je l'ai fait était assez similaire à l' autre que nous avons vu lors la conférence précédente où j'ai présenté le vue d'ensemble d'un projet pour vous. Plus précisément, je viens de cliquer sur File New Project. Et quand cela s'est ouvert, j'ai choisi le système de résolution de dépendances Gradle, choisi Java, puis le JDK de mon choix. Ensuite, je viens de choisir un titre pour cela, même pour les coordonnées de l'artefact, puis je clique sur Terminer, puis j'ai créé mon projet pour moi. Après cela, je viens de construire Gradle et j'ai importé des éléments dans certaines dépendances dont nous aurons besoin pour que ce projet fonctionne. Pour être plus précis que la dette. Utilisé JUnit ainsi que les paquets Mockito. L' API JUnit Jupiter était déjà là après que vous les incluiez. Comme vous vous en souvenez, si vous modifiez n'importe quel caractère du fichier Gradle de construction DC, vous obtiendrez l'auto et avec le bouton de synchronisation sur lequel vous devez cliquer pour qu'il puisse être importé en synchronisation avec toutes les dernières dépendances, directement dans le fichier Gradle de génération. Après cela, la source est classée avec la moyenne et les dossiers de test ont été créés après la création du projet. Dans le dossier Java, j'ai une classe et l'interface. La classe est appelée application de facturation, et l'interface est appelée service de boutique obligataire. Le service de prêt sur gages dispose deux méthodes dont vous avez besoin pour vendre et acheter. Premièrement, ils ne sont pas du tout implémentés dans l'application de facturation. C'est en fait une clinique, pas une interface. J'ai ces champs privés. Il s'agit d'un service de magasin de polices de type, qui était l'interface. Et puis j'ai le service de magasin de grange, qui définit le champ de service de ma boutique obligataire. Ensuite, j'ai une fonction de cellule qui ajoute juste deux chiffres. Le premier devrait être le bénéfice total que le coup de poing a eu jusqu'ici. Et le second devrait en fait être le prix pour lequel nous vendons notre objet spécifique. Encore une fois, ils ne sont qu'à titre d'exemple car ils ne sont pas implémentés dans une mesure où ils seraient intuitifs ou rien par méthode. Cela appelle le vélo du service de poinçonnage qui, comme vous l'avez vu, il n'est pas mis en œuvre, mais nous allons voir comment cela fonctionne en une seconde. Maintenant, là où cela devient intéressant, car jusqu'à présent, il était assez similaire à l'autre projet que nous avons examiné. Facilité au dossier de test, où nous avons créé automatiquement le dossier Java et je crée ces deux fonctions ici. Ce sont les deux classes. L'un est appelé les testeurs d'application de facturation. Ainsi, chaque application de test pour les écrans que vous voyez à l'écran ici ne facturait pas une application. Et puis j'ai un coureur de test qui a la fonction principale dont vous avez besoin, comme nous le verrons dans une seconde, est responsable de l'exécution toutes les différentes classes de bureau que nous aurions dans ce dossier, dans mes contraintes, juste un. Mais dans un projet de production plus important, il peut y avoir beaucoup de lunettes de test. Je sais que c'est assez utile pour exécuter dam plutôt que d' avoir un domaine dans chacun d'entre eux, car il serait beaucoup plus long de cliquer beaucoup plus sur les boutons de chacun des projets. De plus, au test d'application de facturation ici. Comme vous pouvez le constater, c'est assez différent de celui que nous avons vu dans le dernier projet. Et la principale différence est que cette classe de testeur est lue avec JUnit trainer. Et comme vous l'avez vu si vous vous en souvenez, nous importons l'unité d'échange dans mon cas est 4131, la version. Et en expliquant un peu ce que ces points, un coureur JUnit n'est qu'une classe qui étend la classe de coureur de JUnit, ce qui est abstrait. Ces limites sont utilisées pour exécuter les classes de test. Ils ont une certaine patience avec le signe at qui aide le processus de construction comprendre quel objet est la marque, quel objet est l'objet qui doit lui injecter le simulacre, et aussi les fonctions de test. Les tests JUnit sont lancés à l'aide de la classe principale JUnit. Et cela peut être fait en vous exécutant depuis la ligne de commande. Mais dans notre cas, cela sera fait par défaut, par notre IVE lorsque nous allons appuyer sur le bouton Exécuter l'unité de disque qui a la méthode principale. Nous verrons cela dans une seconde. Ces coureurs JUnit utilisent réflexion pour trouver l'entraîneur approprié pour les meilleures lunettes de test. Et bien sûr, il va d'abord chercher l'annotation de la largeur de la rime sur la classe de test, et aucun autre coureur n'est trouvé. Le coureur par défaut sera utilisé. Il sera instancié et la classe de test sera transmise au coureur. Dans notre cas, les dettes, la classe de testeur d'application. Le travail du coureur est d'instancier et de tester le meilleur verre. Donc c'est la course ou est-ce assez simple ? Cela nous aide simplement à exécuter notre test dans Intel J en utilisant des conditions intuitives afin de montrer à l'ID quel composant est le commutateur n. Quel est le rôle de chaque acteur dans ce processus ? Maintenant, passons au coureur d'essais et nous reviendrons dans ce meilleur de sa catégorie dans un peu. Dans la classe de test runner, vous pouvez voir que nous avons la fonction principale et que nous avons un résultat qui est attribué à la méthode JUnit run classes. Et cela est donné en tant que classe de test du paramètre d. Comme je l'ai dit, l' unité de chaîne ou va exécuter la classe des tests. Et bien sûr, ces annotations vont l'aider à le faire. Le résultat est attribué aux classes de jonction JMU. Le noyau de deux minutes classe ce verre à l'aide de la réflexion, puis place le résultat dans cette variable de résultat ici. Nous allons maintenant parcourir ces échecs de résultats. Ainsi, cet objet de résultats a une méthode maximale appelée get failures et il retournera toutes les échecs s'il y en avait dans notre test. Et il va les imprimer à l'écran. Bien sûr, il va également imprimer si notre résultat a été réussi ou pas dans DC va soit imprimer vrai si tous les tests ont réussi ou faux si certains d' entre eux échouaient, comme vous pouvez le voir sur la description à l'écran , c'était à peu près la structure de notre projet. Nous voyons à l'écran. Je voulais juste vous montrer tous les éléments que j'ai faits en détail. C'est le cas si vous voulez suivre ce projet ou peut-être même l'écrire et ensuite modifier que vous êtes en ligne. Vous allez pouvoir le faire. Après cette présentation. Je vais approfondir le concept dont nous allons parler au cours de cette conférence. Et vérifiez la méthode, la classe publique de tests d'application de facturation que j'ai écrits à l'écran ici, fait quelques choses très bien informées au sein du Mockito dans leur décharge, très bon avec ce cadre et c'est pourquoi je voulais vous les présenter. Tout d'abord, il déclare un objet d' application de facturation. L'annotation des marques d' injection teste qu'il s'agit de l'objet dans lequel la marque doit être injectée. Et comme vous pouvez le voir ici, le service de prêteur sur gages est la marque car il ne s'agit que d'une interface et nous devrions l' injecter dans ce verre. Maintenant, nous déclarons également dans ces objets de service testés sur boutique, que nous annotons. C'est en fait un Mock comme vous l'avez vu, en itératant, C'est une interface et nous devrions commercialiser le comportement et le comportement du marché pour retourner exactement ce que nous voulons retourner et qui l' ont réellement mis en œuvre. N'oubliez pas que nous faisons ces opérations afin d'éviter les frais de test de nos classes de production. Soit en ne voulant pas recréer tous les flux de base de données dans un simple simulacre donné par nos valeurs et aussi pour mieux contrôler le flux de pièces qui ne sont pas réellement liées à celle-ci. Et nous voulions simplement tester cette fonction séparément des autres classes. Et maintenant, le test à la fonction, qui est le test unique que nous avons écrit dans cette application. Comme vous pouvez le constater, il est annoté avec le signe de test. Nous allons, tout d'abord, au comportement utilisant Mockito, que lorsque la méthode de vente du service de prêteur sur gages sera appelée avec les paramètres de 1020, dommages devraient renvoyer 30. Nous ajoutons ce comportement sinon cette ligne de code n'aurait pas existé ici. Le service de prêteur sur gages avec la méthode de cellule ne renvoie rien car cette méthode n'est pas un composant, nous avons ajouté le comportement. Ensuite, nous allons tester ces fonctionnalités d'ajout et affirmer si la méthode de vente du service de prêteur sur gages avec les arguments de 1020 retournera en fait 30 S que nous avons demandé de faire. Et nous allons le faire comme vous pouvez le constater avec la méthode assert, qui appartient à la classe JUnit, référence JUnit est très importante ici. Et ensuite, cet endroit a une méthode assert equals, comme vous pouvez le voir, qui prend deux objets et commence ensuite qu'ils soient égaux ou non. C'est assez simple. Maintenant, nous pouvons vérifier le comportement à l' aide de ces mots-clés de vérification et également de méthode. Vérifier le comportement indique que nous devrions vérifier la méthode de vente du service de prêteur sur gages avec les arguments puis dans 20. Cela signifie essentiellement vérifier si la méthode de classe de service de magasin d'obligations de cellule avec l'argument 1020 a été effectivement appelée. Nous pouvons également faire une autre chose en utilisant la vérification. Et cela suggère également l'époque de l'appel de ces fonctions. Maintenant, approfondir connaissances théoriques de la méthode de vérification. Mockito peut suivre tous les appels de méthode que vous effectuez dans le test des méthodes ainsi leurs paramètres pour les objets simulés d' endettement. Vous pouvez le faire en utilisant cette méthode de vérification dont je parle ici même sur l'objet simulé. Comme je l'ai dit, vous devez l'utiliser pour vérifier que les conditions spécifiées sont remplies. Par exemple, vous pouvez théoriquement vérifier que la méthode a été appelée, certains paramètres sont que nous faisons ici à la ligne 30 ce type de test est parfois appelé test comportemental. C'est assez suggestif. Et il ne vérifie pas le résultat d' un appel de méthode copain vérifie que la méthode est appelée avec les bons paramètres. Comme vous pouvez le voir dans ces relevés de vérification en ligne 3333, le résultat réel, qui est 30 et il devrait être 30 sur méthode de la dette qui est marquée nulle part pour être trouvée, donc cela n'est pas du tout impliqué. Le résultat de cet appel de méthode, nous venons de vérifier si la méthode de profondeur a été appelée ou non avec des paramètres rouges et aussi le nombre de fois qu'elle a été appelée. Bien sûr, il peut faire beaucoup d' autres choses que nous allons faire, consulter les conférences ultérieures. Mais dans cette conférence, nous allons nous concentrer uniquement sur ces deux facteurs. En revoyant à nouveau, les méthodes raffinées du jouet de singe sont simplement utilisées pour vérifier que certains comportements se sont produits. Nous pouvons utiliser ces méthodes de vérification à la fin des méthodes de test et c'est ainsi qu'elles devraient être utilisées comme vous pouvez le voir sur mon écran. Pour s'assurer que les méthodes spécifiées que nous appelons vers le haut sont réellement appelées. De cette façon, ayez un autre moyen de vérifier que le flux de travail que nous avons suggéré, cette méthode de test a effectivement eu lieu et que E fonctionne comme nous le pensions. Nous pouvons y aller de l'avant et voir ce qui se passe avec ces fonctions de test. Lorsque vous cliquez avec le bouton droit sur le coureur de test et exécutez-le, il va passer à la fonction principale. Ensuite, en utilisant le noyau JUnit, il va exécuter toutes les classes de cette classe de test. Ensuite, il va parcourir chacune des défaillances, s'il y en a, les imprimer et sinon, ou même s'ils étaient inférieurs, VT va imprimer à l'écran si le résultat a été réussi ou non. Succès, ce qui signifie qu' il y a eu des erreurs ou non. C'est assez intuitif lorsque la méthode JUnit core run classes appelée largeur du test de l'application de facturation. Notre méthode de test va être appelée. abord, nous ajoutons le comportement de la méthode de vente du service sur gages qui appelée avec le premier document est Dan et le deuxième argument est 20, il devrait renvoyer 30. Nous allons maintenant affirmer si le comportement est réellement effectué en affirmant si la méthode cell de cette interface et la valeur réelle et la valeur 30 sont égales. Ensuite, nous allons juste vérifier si cette méthode de cellule, eh bien, elle s' appelle en ligne 29. Et nous allons également vérifier si la méthode cell, arguments du locataire 20, ce qu'on appelle une fois en ligne 20 également. Lorsque nous les exécutons, comme vous pouvez le voir ici, il est dit que la tâche du coureur d' essai Maine était. Invoqué, ce qui était cette tâche ici. Tension anti-confiance à vrai. blanc s'est avéré vrai. Eh bien, c'est parce qu'il a parcouru toutes ces années getfield et a littéralement eu neuf ans parce que notre méthode de test n'a pas connu d'échecs. Et puis il imprime que les résultats ont été couronnés de succès. C'est ce que B est vrai. Tout s'est passé alors que nous plantons ici, notre méthode cellulaire s'appelait. Il a été appelé, en fait, une fois. Voyons maintenant ce qui se passe. Si nous voulons vérifier si la méthode cell avec l'analyse des arguments dans 30 a été appelée. Si nous le lançons à chaque tournage, dites-nous qu'il n'a pas été appelé avec les valeurs 1030, mais avec les valeurs réelles 1020. Et comme vous pouvez le voir ici sur le test de tâche rendu principal, il est dit que les arguments sont différents. Nous voulions que les arguments soient 1030, mais l'invocation réelle qui s'est produite à la ligne 29, comme indiqué ici également, où 1020. Il nous indique donc l'échec en détail comme nous l'avons demandé dans le test Turner en ligne, puis nous imprime également que le résultat n'a pas réussi, donc c'était faux. Continuons maintenant à vérifier ce 1020 pour qu' il le retourne. Très bien, mais maintenant vérifions si la cellule de méthode avec le paramètre standard 20 de l'objet simulé de type punch up service a été appelée deux fois. Encore une fois, il devrait nous avertir et il devrait retourner faux lorsque nous l'exécutons. Comme vous pouvez le voir ici, encore une fois, il retourne faux. Et plus précisément la dette américaine, la méthode de test a échoué. Et la fonction de cellule de service de prêteur sur gages avec ces paramètres voulait être appelée deux fois. C'est donc ce que nous voulons que cela se produise. C'est ce que nous avons indiqué qu'il se produirait. Mais en fait, le nombre d'invocations, c'était une fois. C'est assez simple parce qu'il a été appelé Une seule fois ici à la ligne 26 n'est pas appelée. Il suffit de préciser que lorsque Scott vous devriez retourner 30. Il ne s'agit donc pas réellement d'un appel à l'exécution C. La méthode Verify est extrêmement utile pour vérifier que le flux est spécifié dans notre test a effectivement été exécuté. Non seulement les méthodes que nous voulons que vous appeliez aient été appelées, mais aussi les fois où elles ont été appelées. Le fait qu'il ait précisé que cette profondeur, les choses qui ont mal tourné, est encore une fois très utile car vous pouvez voir à un niveau plus profond ce qui a mal tourné exactement. Et vous pouvez ensuite déboguer beaucoup facilement, vous testez et voyez ce qui se passe mal. Peut-être sur votre bureau en spécifiant la mauvaise chose ou dans votre méthode réelle. La méthode a beaucoup d' autres fonctions complémentaires telles que ces fonctions de temps ici. Et nous allons les examiner en détail dans les prochaines conférences. Mais pour celui-ci, je voulais simplement vous montrer rapidement notre projet de configuration ainsi que les fonctionnalités de la vérification. Encore une fois, en itérant à travers eux que la fonction a été appelée avec certains paramètres et les temps égaux appellent d'autres fonctions complémentaires avec la méthode de vérification dans Mockito vous semble intéressant. Je vous suggère de rester dans les prochaines conférences. Et encore une fois, je suis très reconnaissant que vous m'aidiez jusqu' à la fin de celle-ci. J'ai hâte de vous voir aussi dans le prochain. 9. Vérifier la gamme d'appels de méthodes: Bonjour les gars et bienvenue dans ce tutoriel sur le framework de test Mockito, où nous comprenons mieux comment utiliser ce framework particulier afin de mieux tester nos méthodes écrites dans le langage de programmation de Java. Dans cette conférence, nous allons continuer à comprendre la méthode de vérification du plus en profondeur la méthode de vérification du cadre Mockito. Et vous allez le faire à l'aide d' autres méthodes expérimentales qui peuvent fonctionner avec ces méthodes de vérification et d' autres méthodes connexes pour vérifier la méthode. Le projet que nous examinons, ce qui est présenté lors de la dernière conférence. C'était celui de l'application de construction avec la surface du prêteur sur gages, du service de poinçonnage à nouveau avec l'interface et l'application de construction. Considérant qu'une classe concrète qui utilisait le service de prêteur sur gages dans la méthode des octets. L'application du bâtiment. C'est la classe où nous avons rédigé nos tests unitaires réels, nous Mockito. Et celui-ci n'est qu'une classe réelle qui exécutera tous les tests que nous avons. Un peu hargneux n'est que l' application de facturation après classe. Et la dernière fois, nous avons examiné la méthode de vérification afin de vérifier que la fonction était appelée. De plus, nous avons examiné la méthode complémentaire Times qui fonctionnait avec la vérification de l'ordre pour vérifier nombre exact de fois où cette méthode a été appelée. Mais plus que ces temps fonctionnent, il existe d'autres fonctions complémentaires qui fonctionnent avec cette méthode de vérification de Mockito et qui sont de nouveau très utiles lorsque nous voulons tester nos méthodes unitaires. Il est utile encore une fois pour vérifier que la méthode naturelle du verre que nous testons a été exécutée. Tout d'abord, vous devez vous souvenir la syntaxe générale de cette méthode de vérification, qui est le mot-clé verify. Et puis il peut prendre comme paramètres, tout d'abord, l'objet de la classe que vous voulez tester dans notre classe, c'est le marché de la surface des prêteurs sur gages. Ensuite, il peut éventuellement prendre un deuxième paramètre qui est une fonction. Nous verrons ce que cette fonction fait dans une minute. Mais après cette vérification réelle, vérifiez que la méthode date l'argument uniquement l' objet de Democritus que nous voulons tester. Ensuite, la syntaxe spécifie la méthode de cette classe avec des paramètres réels. Il vérifie non seulement la méthode du graphique que nous spécifions comme premier paramètre, mais également ses paramètres. Le retour au deuxième argument est maintenant facultatif, mais à nouveau donné dans la méthode vérifiée. Il spécifie les réservoirs dont cette fonction a eu des coûts réels. Il peut être deux fois. Et nous en avons parlé la dernière fois, comme je l'ai dit, qui spécifie combien de fois cette méthode réelle avec ces arguments réels a été appelée. Mais il peut également être tout au plus et le réseau spécifie au moins si l'objet de classe en tant que premier paramètre donné à la méthode de vérification et sa méthode avec ces arguments a été appelé dans ce test, au moins. Et puis chacun prend une intégrale quant au nombre de centimes est appelé ou cellule la plus haute. Vous pouvez mettre une limite ici, mais pas seulement cela, nous pouvons également avoir la fonction réseau, ce qui est encore une fois très utile car c'est essentiellement l'opposé de la fonction de vérification simple qui vérifie si la fonction de la dette a été appelée. La deuxième fonction complémentaire ici, qui n'est jamais assurée que la méthode de cet objet dans laquelle ces paramètres spécifiques n'ont jamais été appelés. De plus, que ces fonctions complémentaires que nous pouvons donner en tant que paramètres vérifiés le long du verre marqué Arctic Dr. Nous avons également la méthode pour vérifier qu'il n'y a plus d'interactions. Cela prend le simulacre d'objet comme paramètre. Cela permet de vérifier que toutes les interactions ont été vérifiées. Il supporte la cause réelle des méthodes avec ces objets de classes. Et il vérifie si tous ces coûts sont vérifiés. Et s'il y a des interactions non vérifiées sur cet objet marqué, il renverra false. Nous préciserons que, comme vous pouvez le constater à ce stade, il n'y a pas d' interactions non vérifiées. Comme la méthode de cellule est la seule être appelée et elle est appelée en ligne. 29 c'est que j'ai mis en place la ligne 39. n'existe pas de méthode non vérifiée du service de poinçonnage d'objets. Si nous exécutons le test à ce stade, vous pouvez voir qu'il retournera vrai et que tout est vérifié. Mais ensuite, à la ligne 40, j'ai de nouveau appelé la méthode cellulaire sur le groupe d'objets de service. Et cette fois, je vais écrire à nouveau la vérification de plus aucune interaction. Ce que fait cette fonction, elle vérifie jusqu'au point où elle est écrite. Donc seulement avant cela, s'il y a des interactions non vérifiées des méthodes de l'objet qu'il reçoit en tant que paramètre 41. Maintenant, je spécifie à nouveau cette fonction seulement que en ligne 40, j'ai appelé la méthode du poinçon de service. Comme vous pouvez le voir, avec les arguments de 1020 DC moins importants. Mais l'important, c' est qu'après l'avoir appelé, je ne l'ai pas vérifié. Donc, si nous exécutons cela maintenant, quand il arrive dans les très belles directions normalement ici, on sentira que c'est faux. Et comme vous pouvez le voir, il est dit précisément en détail que connaître les directions où une perle, ligne 41, comme nous l'avons dit spécifiquement avec cette fonction. Mais nous avons trouvé l'interaction du service sur gages simulé à 940. Et cela vous garderait également pour votre propre liste de références de tous les emplacements qui ont été créés pour ces objets moqués en ligne 40 n'a pas été vérifié. En ligne, combat du 29 mercredi. Et cela vous indique que ce signe ici signifie que l' implication réelle n'était pas un combat. Comme vous pouvez le voir les informations en ligne 40, qui est celle où elle n'est pas vérifiée. Et en ligne 29, qui est celui-ci, a été vérifié. y a donc pas de point d' interrogation. Ensuite, si en outre, renvoie faux, comme vous vous en souvenez, c'est le résultat de la ligne 13 indiquant si le résultat de la classe Coran de cheminée du testeur d'application de construction de verre a réussi ou non. Et dans notre cas, il n' a pas été couronné de succès. Il s'agissait donc de ce tutoriel où nous avons examiné à nouveau d'autres méthodes complémentaires sur la méthode de vérification multi-doses. Et nous examinons également la toute dernière interaction plus importante afin de comprendre comment cela fonctionne. Dans le prochain tutoriel, nous allons examiner l'ordre des coûts qui sont effectués et comment les vérifier également. Encore une fois, en utilisant le mot-clé verify. Si cela vous semble intéressant, j'ai hâte de vous y voir. Encore une fois. Merci de rester avec moi. Après la fin de cette conférence. 10. Le cours InOrder: Salut les gars, et bienvenue dans ce tutoriel sur le framework de test unitaire Mockito, Java, où nous comprenons mieux comment nous pouvons tester nos méthodes écrites dans le langage de programmation de Java. Dans cette conférence, nous allons continuer à parler la méthode de vérification, le framework Mockito. Et plus précisément, nous allons vérifier dans cette conférence, l'autel de l'invocation concernant les méthodes des objets. Dans notre classe de tests. Nous pouvons l'utiliser dans la classe d'ordre, comme vous pouvez le voir ici, pour vérifier l'ordre des invocations de différentes méthodes sur notre objet simulé. Nous pouvons en fait ignorer certaines méthodes que nous voulions vérifier. Mais les méthodes que nous voulons vérifier doivent être invoquées dans l'ordre afin que vous puissiez ignorer cette chaîne, bien sûr, à n'importe quel moment que vous le souhaitez, mais la vérification désactivée de la chaîne doit être dans l'ordre réel que vous le donnez dans l' objet dans l'ordre que vous créez. Vous ne pouvez pas ignorer les coûts entre les coûts que vous essayez de faire. Avec l'objet en ordre. En regardant le code à l'écran, vous pouvez voir à la ligne 40, comme je l'ai dit, j'ai déclaré un objet de type dans l'ordre, qui est une interface disponible dans le framework Mockito. Et cela prendra en fait un type d'objet dans l'ordre, simulacre, le seul paramètre. Ensuite, en utilisant les objets dans l'ordre que nous créons, nous pouvons faire appel la méthode vérifiée qui prend, comme nous le savons, comme premier paramètre, l'objet moqué que nous avons dans la classe de test. Et il peut éventuellement prendre un autre paramètre qui spécifie le nombre de fois que l' appel a été effectué. Et c'est le Phi disparate. Nous avons la syntaxe que nous connaissons maintenant, pointer la fonction que nous voulions tester pour obtenir le code de l'objet moqué et ensuite ses paramètres. Ligne solide 41. Je suis très bien avec l'objet dans l'ordre, si la cellule de service punch up avec l'argument 20 a été invoquée et essayez-la après. Je vérifie si la méthode de cellule du groupe d'objets de service avec les arguments puis dans 30 a été appelée deux fois. Et puis, après cela, je teste si la méthode bind avec les arguments de 1035 du groupe d'objets de service a été appelée. Nous vérifions à nouveau l'ordre des invocations de discours sur le marché. Object avec ceux-ci afin de classer et de plus, vérifier la méthode. Comme vous pouvez le voir, j'ai changé un peu le code avant l'appel de cette méthode. Et en ligne 30, nous avons la cellule du service de prêteur sur gages avec la cellule argument 20. Il s'agit du début de la vérification des appels de chaînage. Ensuite, nous avons en ligne 35362 cos de la méthode cell avec les arguments est fait dans 30. Et vous pouvez voir que c'est ce que nous testons sur la ligne 42. Et enfin en ligne pour D3, nous testons si la méthode de liaison que nous documentons la norme 35 a été appelée ensuite, quel taxi était H peut voir en ligne 35. moment, si nous gérons ce cours, vous pouvez voir qu'il va revenir vrai. Mais que se passe-t-il, par exemple, si au lieu d'appeler la méthode avec les arguments, alors dans 35, je l' appellerais documents standard 45. Avec ceux-ci fonctionnent encore bien théoriquement maintenant, vous pouvez voir à l'écran que cela ne fonctionne pas. Et manger encore spécifie en détail, ce qui est une caractéristique très utile que la vérification de l'inordre, c'était un échec et 35 méthode était recherchée mais pas invoquée. Il a été recherché n'importe où après l'interaction suivante, soit le 1030. Mais cette invocation réelle n' a jamais été appelée. Ec2 attend le 1035, il a en fait 45. Et la méthode de la fonction objet de service avec l'argument standard cinq n'a jamais été appelée dans la séquence. Cette fausse erreur a été signalée ici. C'était à propos de cela, la fonction in-order disponible dans le framework multiple peut être très utile si vous souhaitez vérifier une séquence d'appels que vous effectuez dans votre classe de test. J'espère que vous avez tiré quelque chose de ce tutoriel. Merci beaucoup de rester avec moi jusqu'à la fin de ce tutoriel. Et je vous verrai dans le prochain. 11. Accords d'argumentaire: Bonjour les gars et bienvenue dans le tutoriel sur les petites cétones. Dans cette conférence ici, nous allons discuter de Mockito, matchers d' arguments et plus précisément d'être Amy Matcher dans le cadre de démonstration Quito. Ce sont des éléments très importants dans le cadre Mockito et nous verrons pourquoi dans un instant. Maintenant, en abordant un peu les choses dont nous avons déjà parlé, Mockito nous a permis de créer les objets simulés et d'y ajouter un comportement. La façon dont le comportement a été ajouté était par les mots-clés quand puis retourne le mot-clé, l'objet simulé. Et rappelez-vous que nous avions le mot-clé when et ensuite paramètre a pris la fonction de debt mock objet et aussi ses paramètres. Ensuite, le mot-clé retour suivi du document. Ce que cette méthode des objets marqués avec ces paramètres spécifiques doit être lue ici. C'est ainsi que le Danemark. Ajoutons un comportement spécifique, comportement marqué, bien sûr, à nos objets du mois, juste pour que nous puissions les faire retourner exactement ce que nous voulons. Maintenant, bien sûr, jusqu'à ce point où vous voyez un double ici, nous avions des valeurs réelles comme vous les voyez sales ici. C'était une façon assez générique de se moquer du comportement d'un objet simulé. Mais les derniers matchers d'arguments faibles de Mockito font un moyen joli, simple et beaucoup plus large vous permettre fondamentalement de marquer ce comportement. Supposons que nous voulions marquer le comportement de n'importe quel argument du type donné. Dans ce cas, nous pouvons utiliser cette matrice d'arguments dont je parle. Ils sont définis dans la classe Mockito, matrice d' arguments et ce sont des méthodes statiques. Comme vous le voyez, nous pouvons simplement les appeler ici. Nous avons parlé de n'importe quel objet lié à eux. Nous pouvons les appeler par leurs propres moyens. Comme vous pouvez le constater, au lieu d' écrire des valeurs spécifiques ici, nous pouvons écrire cette double fonction. Et ce que cela va faire, il renverra 34, en fait, toutes les valeurs doubles reçues en tant que paramètres sur la même méthode que le service Marked Objects, LB de la classe de service. Et comme vous pouvez le constater, j'ai fait un tas d'affirmations ici qui ont un tas d'arguments différents qui sont assez différents les uns des autres. Et pour chacun d'entre eux, j'ai précisé qu'il devrait en renvoyer 30. C'est juste un moyen pour nous de tester que ce comportement d'adulte ici avec l' argument important dans Mockito fonctionne réellement. Si nous cliquons dessus avec le bouton droit de la souris et que nous cliquons sur Exécuter, vous verrez que pour chacune de ces méthodes de cellule avec tous ces différents arguments, ces méthodes renvoient en fait 30, peuvent le voir. retourne vrai. Si vous vous souvenez que c'est le résultat de la méthode réussie, la méthode de classe incorrecte sur JUnit. Pour l'argument de notre classe de test. Il fonctionne réellement. Cette matrice d'arguments est donc à nouveau très utile, si vous voulez faire un comportement général simulé et que vous ne vous souciez même pas arguments que la fonction reçoit. Pour tout argument qu'il peut recevoir, suffit de renvoyer le même résultat. Peut-être parce que vous voulez tester la méthode et qu'il y a une autre méthode dans cette méthode et que vous êtes allé sur le marché. Donc, vous voulez simplement manger cette fonction et aucune autre fonction. Et s'il y a une autre fonction, vous êtes allé vous moquer d'eux pour rendre une valeur esthétique qui, dans ce cas, serait, comme je l'ai dit, 30. Et dans ce scénario, les dettes sont une chose assez précieuse que Mockito vous permet de faire, plus de la méthode N double. Bien sûr, nous avons des booléens et ainsi de suite. Pour chaque type de données auquel vous pouvez penser, n'importe quelle méthode, vous pouvez remplacer n'importe quel type de données pouvant être donné comme argument de la méthode Where. Mais merci beaucoup de rester avec moi jusqu'à la fin de cette conférence. Et dans le prochain, nous allons discuter des espions. Dans le cadre de Mockito, nous allons examiner ce qu'ils sont exactement et comment ils peuvent être utiles pour demander lors du test unitaire de nos méthodes. Cela vous semble donc intéressant. J'ai hâte de vous voir les gars. Là. 12. Espaces: Bonjour les gars et bienvenue dans ce tutoriel Mockito, où nous comprenons mieux comment tester nos méthodes écrites dans le langage de programmation Java. Dans cette conférence, nous allons discuter de Spice, Mockito framework. Et comprenez également ce qu'ils sont exactement et comment ils peuvent être utiles lors d'un voyage. Pour écrire ces tests unitaires, nous pouvons utiliser un espion Mockito pour se moquer partiellement d'un objet. Se moquer partiellement d'un objet, c'est se moquer d'un objet de dette. Mais lorsque nous créons cet espion à partir d'un objet, ces méthodes réelles des objets sont appelées, même s'il s'agit d'un objet simulé. Maintenant, j'ai à l'écran une implémentation qui sera un excellent exemple pour cette définition et qui vous aidera à comprendre exactement ce que sont Spice. Vous connaissez bien ce projet dans Intel J, nous n'avions pas créé l'application ici. Et aussi un objet simulé. L'objet simulé a été injecté dans le bâtiment de l'application, ce qui était en fait une méthode concrète. Maintenant, sur notre méthode de test, j'ai tout d' abord ajouté le comportement que le service de prêteur sur gages, qui était l' objet marqué dans le cas où la méthode cellulaire était appelée avec deux double quoi que ce soit, c'est des arguments puis H2, H3, stylo sale. Maintenant, ce qu'ils ont fait, j'ai déclaré un objet de type d'application de facturation, et je lui attribue un espion sur l'objet de l' application de facturation. Ensuite, ce que j'ai fait, j'ai appelé sur cet objet pie la méthode de cellule, la largeur, les arguments de 1020. Classe d'application de facturation morte. La méthode cellulaire. Je l'ai fait implémenter pour qu'il retourne et l'imprime à l'écran, la somme des deux nombres qui sont donnés en tant que paramètres. Après cela, j'ai également créé un objet de type service de prêteur sur gages en ligne 34, et ils sont affectés à manger le SPI de l'objet de service prêteur sur gages. Il s'agissait en fait de l'objet moqué dans cette classe de test. Et ce qu'ils ont fait. De plus, j'ai imprimé la méthode cellulaire de cet objet espion avec les arguments 2323. S'il ne s'agissait pas d'un espion sur le service de prêteur sur gages, il devrait en rapporter 30 car c'est ce que nous faisons. Si la méthode de cellule de l'objet service prêteur sur gages est appelée avec deux doubles , elle devrait par défaut, renvoyer 302223 est deux doubles. Et quand nous exécutons cela, vous pouvez tout d'abord voir que celui-ci renvoie 30. Parce qu'alors et 20, c'est 30. Et j'imprime strictement sur l'écran la somme des deux paramètres. De plus, il renvoie 0. Et pourquoi est-ce que c'est 0 ? Parce que l'objet de service de poinçonnage est en fait un verre simulé, qui n'était qu'une interface. Et la méthode cell n'est pas réellement implémentée, elle renvoie donc le double par défaut, qui est 0. Si ce n'était pas un espion, et que nous avons eu ici plutôt que SPI au service de prêteur sur gages. Vous pouvez voir que par défaut, il renvoie 30. Comme vous pouvez le voir ici, car c'est ce que le comportement de celui-ci alors return n'a pas besoin de faire. Donc. C'est la différence entre un objet marqué avec un comportement ADD et un objet espion non marqué. L'espion de l' objet simulé appellera en fait la méthode réelle de cet objet. Nous pouvons également utiliser à la place de la classe Spy pour appeler la méthode réelle, méthode sur un objet marqué pour appeler la méthode réelle. C'est également une variante ici, mais ce n'est pas recommandé et il est recommandé d' utiliser un espion pour ces marques partielles. Et la principale raison en est que l' espionnage des poulets que nous avons est en fait instancié. Lorsque nous créons un objet simulé, le singe TO crée une instance d'un objet, qui est à peu près le squelette de celui-ci. Donc, avec le strict minimum, et il est possible que ces dépendances requises ne soient pas ces dépendances requises ne soient pas initialisées lors de la création du marché avec le Mockito. Et cela peut aboutir à de mauvais résultats en fin de compte. Et c'est pourquoi les épices sont en fait préférées au lieu de la méthode du code ci-dessous, méthode également disponible dans ce contexte. J'espère donc que vous avez tiré quelque chose de ce tutoriel et que vous avez compris ce que sont les espions et comment ils peuvent nous être utiles. Merci encore d'être resté avec moi jusqu'à la fin de cette conférence. Et j'ai hâte de vous voir dans le prochain.