[MUSIQUE]
Le parfum du jasmin de toutes ces guirlandes de fleurs
sur la rue du temple qui se répandait dans les airs.
Quel sentiment de règlement.
Ça doit être le bon karma de ma vie passée.
Désolé, où étais-je ?
Je te parlais de tests angulaires, non ?
Et nous allons utiliser l'ajustement du karma pour faire nos tests angulaires.
Alors allons-y.
Une bonne chose à propos de l'utilisation de l'interface de ligne de commande Angular est qu'il configure tous les échafaudages pour
vous pour inclure automatiquement le support pour
tester votre application Angular.
Donc, vous remarquerez que chaque fois que vous générez un composant ou
un service avec les fichiers ts du composant,
vous remarquerez également un fichier appelé component.spect.ts
déjà inclus dans vos dossiers de projet.
Et aussi, si vous allez dans le fichier package.json,
vous verrez qu'il y a déjà un support pour les tests Angular inclus.
Donc, si vous allez dans les dépendances de dev, vous verrez que le noyau jasmin,
le reporter spec jasmin, les modules npm liés au karma et
karma sont déjà installés dans votre application angulaire
qui est échafaudage par Angular CLI.
Donc, nous avons toutes les choses et la place pour
nous pour simplement faire nos tests pour notre application angulaire.
Donc, si vous regardez autour, vous verrez qu'il y a
un fichier appelé test.ts dans votre dossier source,
alors ouvrons le fichier test.ts.
Vous verrez également qu'il y a un autre dossier appelé à e2e.
Nous reviendrons à cela dans le prochain exercice.
Mais dans le dossier test.ts, vous verrez que c'est là que
votre support karma est configuré ici.
Donc, en entrant dans ce fichier test.ts, par défaut,
lorsque vous utilisez le support CLS angulaire pour le test,
il exécutera les tests pour tous les composants et services
qui sont inclus dans votre application angulaire.
Maintenant, je vais vous illustrer comment faire des tests pour
un composant spécifique, le MenuComponent.
Donc, je veux me limiter à utiliser uniquement le composant de menu .spec fichier et
faire les tests pour seulement le composant de menu.
Alors, allez dans le fichier test.ts.
Une façon de configurer le test des CLIS angulaires pour exécuter le test uniquement pour
un composant spécifique est d'aller à cette ligne ici,
qui dit contexte const et puis changer ceci en menu,
vous pouvez voir /menu \ .component et fichier spec.ts.
Auparavant, c'était juste le fichier/ \ .spec.ts, ce qui signifiait que vous
exécuterez tous les fichiers spec qui se trouvent dans votre dossier source de projet.
Donc, en ce moment, en spécifiant ceci ici,
Je suis intéressé à exécuter le test uniquement pour le fichier de spécification du composant de menu ici.
Maintenant, je comprends en cherchant autour du débordement de pile
où j'ai trouvé quelqu'un me donnant la réponse à cela,
pointant vers une ressource sur Angular CLI, et donc
c'est ainsi que j'ai compris que c'est la façon de restreindre
le test au fichier de test d'un composant spécifique.
Donc, après avoir apporté une modification au fichier test.ts, sauvegardons la modification.
Maintenant, nous allons essayer d'exécuter notre test sur le composant de menu.
Ainsi, comme vous le voyez, dans le composant menu, nous avons déjà le fichier .spec.ts du composant menu
, qui contient déjà du code.
Essayons de faire ce test et de voir ce qui se passe.
En allant au terminal, ajoutez l'invite, tapez ng test, et ce
entraînera une CLI angulaire démarrant le test pour le composant de menu.
Donc, lorsque vous tapez ceci et appuyez sur le retour,
alors Angular CLI commencera à compiler votre application angulaire.
Il va également ouvrir une fenêtre de navigateur, dans mon cas, il va ouvrir une fenêtre de navigateur Chrome
et ensuite utiliser cette fenêtre de navigateur pour exécuter le test.
Et vous voyez que dans le dos, vous avez la fenêtre du navigateur Chrome en cours d'exécution et
il est plein de rouge et tout un tas de mots là-bas.
Les mêmes informations seront également imprimées dans votre fenêtre de console,
et à partir de cela, je peux voir que mon test n'a pas fonctionné correctement.
Il y a quelque chose qui n'est pas configuré correctement dans mon fichier de test, donc je vais devoir aller et
modifier mon fichier de test pour inclure le support approprié pour exécuter ce test correctement.
Alors allons au fichier spec.ts du composant de menu et
, puis préparons notre test en conséquence.
Maintenant, nous pouvons laisser le test ng courir ici.
Chaque fois que vous apportez des modifications au fichier mini component.ts ou
au fichier mini component.spec.ts et
enregistrez les modifications, ce test s'exécutera automatiquement à ce moment-là.
Alors, allons au fichier MenuComponent.spect.ts.
En allant dans le fichier MenuComponent.spect.ts,
, nous comprenons que le fichier spect utilise la syntaxe Jasmine pour décrire le test.
Donc, vous avez déjà remarqué qu'il y a quelque chose ici
qui commence par décrire et puis il y a une fonction définie là-dedans.
C'est donc ce à quoi je faisais allusion quand j'ai parlé de la syntaxe Jasmine plus tôt.
Et aussi si vous faites défiler vers le bas, vous verrez un ou deux là-dedans.
Et en plus, vous verrez quelque chose appelé BeforeEach, ici.
Examinons ce fichier un peu plus en détail pour comprendre comment ce fichier
est configuré, et comment ce test est configuré dans ce fichier particulier.
Donc, dans ce fichier de test, vous remarquerez que
nous importons ici un ensemble de classes de test de noyau angulaire.
Ainsi, ce module vous permet de fournir le support de test pour
votre application angulaire, et vous permet de concevoir le test pour votre composant.
Donc, vous voyez que j'importe async et
ComponentFixture et TestBed à partir de cette bibliothèque de tests.
Je vais l'appeler bibliothèque de tests.
Vous voyez également que MenuComponent est également importé ici.
Maintenant, une fois que nous avons compris ces deux-là,
nous allons descendre le code pour comprendre ce que nous essayons de faire ici.
Donc, ici, comme vous vous y attendez, cette description ici est
spécifiant que cette fonction particulière décrit,
Un test basé sur Jasmine que nous spécifions pour notre application Angular.
Donc, quand vous regardez la description ici,
vous verrez que cela inclut tout ce code ici.
Donc, cela fait partie d'un seul ensemble de tests que nous exécutons sont notre composant de menu
.
Donc, à l'intérieur de la description, vous verrez qu'il y a une chaîne ici.
Ceci spécifie cet ensemble particulier de tests que vous exécutez ici.
Donc, il est dit sur le composant de menu.
Donc ici, vous pouvez spécifier la chaîne que vous voulez.
Vous pouvez l'utiliser comme description pour
spécifier ce que fait cet ensemble de tests particulier.
Alors ici, je vais rester avec une chose avant.
Nous essayons de tester le composant de menu.
Et après cela, vous voyez que nous spécifions une fonction addo ici.
Dans cette fonction addo, nous allons construire le test.
Pour notre MenuComponent ici.
Donc, après cela, vous verrez que nous déclarons une variable appelée composant,
qui est du type MenuComponent.
De temps en temps, nous déclarons également une variable d'installation,
qui est du type ComponentFixture.
Qui est du type MenuComponent.
Maintenant, pourquoi est-ce intéressant ?
Maintenant, dans notre application Angular,
nous avons le MenuComponent que nous avons déjà conçu.
Donc, dans ce fichier de test,
, nous allons créer ce MenuComponent en utilisant le TestBed angulaire,
et ensuite nous allons effectuer les tests sur le MenuComponent.
Nous allons donc isoler le composant MenuComponent, et
ensuite effectuer des tests unitaires sur ce composant spécifique.
Maintenant, c'est là que les utilitaires de test angulaires
qui viennent avec le support en utilisant TestBed.
Le TestBed me permet de configurer l'environnement dans lequel
je peux tester mon composant angulaire.
Donc, ici, vous voyez que nous disons TestBed et
, puis appelons la méthode du module de test de configuration de la classe TestBed ici.
Et à l'intérieur de ce module de test de configuration,
vous pouvez déclarer un tas de choses, et vous me verrez en ajouter plus ici.
Cela agit exactement comme la configuration du module NG
que vous faites pour notre module at là-bas.
Donc toutes les informations dont vous avez besoin pour
configurer le MenuComponent seront déclarées ici.
Donc, la partie de modèle NG que vous avez vu dans le module d'application,
type similaire de syntaxe peut être utilisée ici pour déclarer le support pour
tester le MenuComponent ici.
Et aussi après cela, vous verrez cette fonction appelée à CompileComponents.
Donc, cette méthode compilera le MenuComponent et
le rendra prêt pour faire les tests.
Notez aussi que toute cette chose, cette fonction ici,
est enfermée dans quelque chose appelé asynchrone ici.
Maintenant, pourquoi avons-nous besoin de cet asynchrone ?
Maintenant, parce que la préparation des composants à l'aide de cette méthode
CompileComponents prend un certain temps.
Et tant que ce n'est pas terminé, nous ne pouvons pas poursuivre les tests.
Donc, en utilisant le module asynchrone, nous spécifions essentiellement que
je vais attendre que tout cela se termine avant de continuer.
Donc, le module asynchrone comme vous le voyez,
enveloppe une fonction de test dans une zone de test asynchrone.
Donc, ce que cela signifie est que ce test terminera automatiquement
lorsque tous les appels asynchrones à l'intérieur de cette zone sont terminés.
Donc, c'est ce que fait l'utilisation de l'asynchrone que nous avons ici.
Donc ce que cela signifie est que vous pouvez utiliser cette fonction de synchronisation,
soit dans le avant chaque ou dans le il aussi, donc dans le dedans, notre déclaration.
Donc, quand vous le voyez aussi, vous verrez que vous pouvez utiliser l'asynchrone.
Donc, au cas où vous auriez des opérations ici qui se sont faites de manière asynchrone.
Ensuite, vous devez attendre que ces opérations se terminent pour que ce test soit terminé.
Donc, par exemple, si vous appelez un service et attendez que
le service renvoie la valeur alors.
Tout ce qui doit être complété avant de pouvoir continuer.
Donc, ceux-ci sont activés en utilisant cette asynchrone, pour entourer cette fonction ici.
Maintenant, en plus, le second avantChaque, maintenant nous avons séparé
ceci en deux séparés avantChaque ici, parce que nous voulons que cela se termine.
Et ce CompileComponents va prendre un certain temps,
surtout si votre composant utilise un modèle externe,
comme nous le faisons dans notre MenuComponents.
Donc, il faut un certain temps pour que le modèle externe se prépare pour
mes tests pour aller de l'avant.
Donc, nous devons attendre que tout cela se termine.
Alors c'est pourquoi une fois que cela est terminé,
alors nous arriverons à la deuxième partie où nous allons
obtenir quelques références à certaines valeurs du banc d'essai.
Maintenant, qu'est-ce que c'est avantChaque fonction que vous faites ici ?
Ce que le BeforeEach signifie est que tout ce que vous déclarez à l'intérieur ici,
cette fonction sera exécutée avantEach test,
que vous allez spécifier plus tard en utilisant le.
Donc, en utilisant ce BeforeEach, vous pouvez configurer la configuration initiale
pour que votre test continue.
Donc, ce qui signifie qu'ici, nous sommes en train de mettre en place notre TestBed,
préparer notre composant de menu, puis mettre en place quelques choses pour
notre composant de menu, avant de procéder au test.
Donc, pour chacun des tests que vous allez spécifier en utilisant un it ici,
ceux-ci avant chaque ce que vous spécifiez dans ce avant chaque,
sera exécuté avant que le test ne soit effectué.
Donc, comme vous pouvez le voir, je prépare le TestBed.
Puis après, j'ai accès au luminaire.
Donc j'utilise le TestBed, je dis CreateComponent et MenuComponent.
Donc, cela me retournera une référence au MenuComponent que
je crée dans mon script de test ici et
ensuite obtenir une référence à cela, car j'aurai besoin d'une référence à
cela pour y faire quelques manipulations.
De plus, à partir du luminaire, je reçois un accès à l'instance de composant
qui est créée par mon luminaire de composant ici.
Donc, comme vous pouvez le voir, l'appareil de composant du type MenuComponent et
appelant ensuite ComponentInstance, me donne accès à ce composant de menu spécifique
que j'ai créé à l'intérieur du TestBed pour effectuer les tests unitaires.
Maintenant, après cela, nous appelons ça ça DétectChanges.
Maintenant, ce que cela signifie, c'est que cela ne se poursuivra qu'une fois tous les changements
terminés, puis reconnaîtront que les changements sont terminés.
Ainsi, cela déclenchera un cycle de détection des modifications pour ce composant.
Donc ce que cela signifie est que cela garantira que vous avez fait des changements
plus tôt, que tous les changements sont détectés et
tout est stabilisé avant de pouvoir poursuivre votre test.
Maintenant, après cela, nous allons l'utiliser pour configurer notre premier test ici.
Quel est le premier test que nous faisons ici ?
Le premier test,
, ce que nous allons tester est de s'assurer que le composant a été créé.
Donc, ici, j'utilise la syntaxe Jasmin et je le dis.
Et puis ici vous pouvez donner une description sous la forme d'une chaîne
pour spécifier ce que ce test teste réellement.
Donc, ce que nous disons est,
, nous testons pour voir si le composant a été créé ou non.
Donc, pour ce faire, je dis que cela devrait créer un sens que,
cette configuration ici aurait dû créer le composant correctement.
Donc c'est pourquoi à l'intérieur ici, j'utilise cette méthode appelée attendre.
Donc, la méthode attendue à l'intérieur ici prend une valeur ici, et
alors vous pouvez tester pour voir si cette valeur satisfait quelque chose.
Donc, ici, nous disons tobeTruthy, ce qui signifie que cette valeur particulière doit être vraie.
C'est ce qui est spécifié par cette méthode appelée ici TobeTruthy.
Vous pouvez également dire TobeFalsy, ce qui signifie que devrait évaluer à faux.
Mais dans ce cas,
nous testons pour nous assurer que le composant a été créé correctement.
C'est pourquoi nous disons que nous attendions à BeTruthy ici.
C'est donc un test simple que nous faisons pour nous assurer que notre composant
est correctement créé.
Mais comme nous le réalisons quand je lance ce test, il ne fonctionne pas correctement.
Regardons rapidement et voyons quel est le problème dans
notre création de composants dans la fenêtre de la console là-bas.
En revenant à la fenêtre de la console, laissez-moi simplement revenir en arrière et
voir où est le problème.
Et je commence à remarquer que cela spécifie qu'il ne semble pas
reconnaître certaines des choses que mon composant utilise.
En particulier, il dit que le MDSpinach
est quelque chose qu'il ne reconnaît pas,
la MDGetGridList et quelques autres choses.
Cela me suggère immédiatement que j'ai besoin de faire quelques autres configurations
dans mon fichier de test avant que mon test puisse fonctionner correctement.
Alors, revenons à notre fichier de spécifications et y apportons quelques modifications.
En revenant à notre fichier de spécifications,
à partir de notre mémoire de la façon dont nous avons créé le modèle.
Nous savons que dans le modèle, nous avions un lien de routeur dans le modèle
du MenuComponent.
J'ai donc besoin d'un support pour le routage afin de reconnaître ce lien du routeur
que nous avons utilisé dans le fichier MenuComponent.html.
C'est donc là que je vais importer
un autre support de test fourni
appelé RouterTesttingModule,
qui est disponible à partir de la bibliothèque Angular/router/testing ici.
Donc, ce module de test de routeur me permettra de
configurer certains aspects de mon routeur.
Nous verrons que la façon dont nous l'utilisons est un peu différente du module de routeur
que nous avons utilisé dans notre application.
Donc, nous allons importer le module de test de routage, aussi vous notez
que nous utilisons des animations, et
utilisant également le composant de matériau angulaire dans notre modèle.
J'ai donc besoin d'importer
le BrowserAnimationsModule dans mon fichier de test.
Donc, cela vient de l'angulaire/plateforme/navigateur.
Maintenant, vous remarquerez que nous devons le faire explicitement ici simplement parce que,
dans l'application Angular réelle tout cela était dans le module d'application,
et donc cela était disponible pour les composants.
En ce moment, nous testons ce composant, le MenuComponent en isolement, donc
c'est pourquoi il ne connaît pas toutes ces choses, donc
nous devons spécifier explicitement toutes ces choses ici.
Donc, je vais importer cela à partir de l'animation du navigateur de la plate-forme de messagerie instantanée ici.
Donc angular.platform.browser animations importer le module
animations navigateur ici.
Laissez-moi inclure le module de couche flex, donc
J'inclurai Angular FlexLayout.
Donc, ceux-ci sont nécessaires parce que j'ai besoin d'eux dans le modèle,
Je vais également importer ce plat de,
partagé/Dish parce que comme vous le verrez plus tard,
J'ai besoin de configurer, A,
DishService parce que mon MenuComponent
dépend du DishService donc
J'ai besoin que aussi en place.
Bien que vous verrez que je vais arrêter ça.
Je vais expliquer cela dans un court moment, et aussi j'ai besoin d'importer quelques autres choses.
Je vais importer des plats de,
vous vous rappelez que nous utilisons cette constante appelée DISKS
que nous avons exporté à partir du fichier shared/dishes.ts.
J'en aurai besoin pour configurer quelques autres choses.
Je vais aussi importer le BaseURL.
Que j'ai déclaré dans le fichier url, Shared/Base
.
Et aussi, j'ai besoin d'importer
l'Observable de,
rxjs, slash, Parce que j'
utiliserai aussi Observable un peu plus tard, quand je configurerai quelques choses.
Alors maintenant, j'ai importé toutes ces choses.
En descendant dans la configuration TestBed, vous voyez que cette partie
est exactement comme le décorateur de module moteur que nous avons dans le module app.
C'est donc là que je peux aussi utiliser les importations juste
comme je l'ai fait avec le module moteur.
Et dans les importations, je vais importer le module BrowserAnimation
parce que c'est quelque chose que j'ai besoin, et
puis importer aussi le module FlexLayout.
Et aussi le RouterTesttingModule parce que
j'aurais besoin du RouterTesttingModule pour configurer quelques choses.
Maintenant, lorsque vous utilisez le RouterTesttingModule, vous devez utiliser cette méthode
appelleWithRoutes au lieu d'utiliser ForRoot comme nous l'avons utilisé avec le module de routeur ici.
Donc, dans ce WithRoutes, vous pouvez spécifier quelques routes
par défaut dont vous avez besoin pour votre application spécifique ici.
Je vais juste configurer un seul chemin ici,
et c'est assez bon pour moi pour tester ce module ici.
Donc, je vais juste dire chemin : 'menu',
et composant : MenuComponent.
Puisque les modèles MenuComponent utilisent certains composants matériels,
allons-y et importez-les.
Nous allons donc importer le MatGridListModule
de @angular /material/grid-list et
aussi le MatProgressSpinnerModule de
@angular /matériel/progress-spinner.
Et une fois que nous les avons importés, alors allons de l'avant et
les inclure dans les importations en bas là-bas.
Alors ajoutons dans le MatGridListModule et le MatProgressSpinnerModule.
Et c'est tout ce dont j'ai besoin pour que
ces importations particulières soient configurées ici.
Donc, avec les importations, nous avons les déclarations où j'ai
le MenuComponent étant utilisé ici, je peux également configurer les fournisseurs ici.
J'ai donc besoin de configurer les fournisseurs ici.
Maintenant, c'est là que nous allons
pour créer quelques talons ici, donc
je dirai fournir : DishService.
Maintenant, le DishService que nous allons utiliser ici ne sera pas le vrai DishService
.
Lorsque vous testez un composant, vous ne voulez pas utiliser un vrai service.
Au lieu de cela, vous risquez de casser le service, et
utilisez ensuite un DishService stub, que je vais appeler en tant que DishServicesTub.
Donc, je dirai, UseValue : DishServicesTub.
Donc, ce serait une fonction stub que j'utiliserai dans l'ordre
pour marquer le DishService ici.
C'est donc celui dont je vais faire usage.
Et aussi le second que je vais utiliser est BaseURL,
que je vais utiliser comme base
que nous avons déjà importé plus tôt.
Donc, maintenant, avec cela, j'ai réellement configuré mon module de test,
alors notez que la façon dont nous spécifions cela est exactement comme la façon dont
nous spécifions le décorateur de module NG pour notre module d'application.
Et ici, nous ne configurons que ceux qui sont requis par le MenuComponent, donc
Je n'ai pas les autres que nous utilisons dans le module d'application lui-même.
C'est ainsi que nous allons configurer le module de test.
Maintenant, la seule chose qui manque est ce DishServicesTub.
Donc, ce que je vais faire est de
implémenter une fonction ici et
appel qui laisse DishServicesTub
être un simple objet JavaScript ici,
que je vais le laisser agir à
place du vrai service.
Nous pouvons casser des services comme celui-ci comme on le voit ici.
Donc à l'intérieur ici, je vais juste à
fournir une fonction simple,
la fonction GetDays ici,
qui retournera Observable du type de tableau Dish.
C'est donc exactement comment la valeur de retour a été configurée là.
Et je vais retourner
un observable de plats ici.
Donc, en utilisant cette fonction stub ici,
ce que je fais est que je tache le DishService, et
puis le configurer avec cette seule méthode dont j'ai besoin pour
mon cache, en disant getDish, et quand cette méthode est appelée,
je vais juste retourner cette valeur.
La constante des plats, ici.
Donc de cette façon, maintenant vous pouvez voir que comment je contrôle ce qui est
fourni au composant à partir d'un DishService stub que je viens de créer ici.
C'est ainsi que vous allez créer des talons pour votre DishService.
L'autre approche que nous pouvons utiliser pour les cas
où nous utilisons des services est appelée comme utilisant l'espion.
Jasmine supporte quelque chose appelé Spy, qui nous permet d'espionner les appels de fonction,
, puis de capturer les appels de fonction, puis de répondre à ces appels de fonction.
C'est donc une autre façon d'utiliser un faux service à la place du vrai service.
Maintenant, nous sommes en mesure de contrôler ce qui est fourni à notre composant de menu.
Donc, après ces modifications, alors nous allons
aller dans notre avant chaque méthode ici.
Après l'asynchrone, ce que je vais faire
est que je vais mettre la main sur le DishService.
Donc vous voyez que j'utilise le banc d'essai, puis j'utilise la méthode get
du banc d'essai pour obtenir un DishService qui a été créé ici,
de ce talon particulier que nous avons déclaré ici dans les fournisseurs.
Donc cela me donne une référence au DishService afin
que je puisse appeler les méthodes du DishService partout où j'ai besoin ici.
Donc, après avoir apporté ces modifications, sauvegardons les modifications et
puis voyons comment notre CLI Angular exécutera ce test après ces changements,
et si notre test réussira à ce stade ou non.
Alors sauvegardons les modifications.
Dès que vous enregistrez les modifications, vous remarquerez que votre test NG
recommencera à relancer notre test.
Donc, il compilera l'application, puis réexécutera le test.
Et voilà, notre test a passé avec succès après
en apportant les modifications à notre fichier component.spec.ts.
Donc, notre premier test, ce qui signifie que nous sommes maintenant en mesure de créer un composant de menu
à partir de notre menu, le fichier component.spec.ts là-bas.
Donc, notre configuration de test fonctionne correctement.
Maintenant, je peux entrer et faire des tests plus intenses dans mon composant de test.
En revenant à ce fichier de menu component.spec, permettez-moi d'ajouter dans un autre test.
Maintenant, vous voyez que parce que j'ai maintenant un service établi ici
qui retourne cette valeur DISS, je peux maintenant utiliser mon DishService,
auquel j'ai la référence ici.
Inside était avant chacun, puis appelez la méthode getDats et
alors je serai en mesure d'obtenir la valeur.
Et cela sera disponible dans mon composant de menu que je viens de créer.
Donc, mon MenuComponent devrait maintenant avoir accès à la constante de vaisselle que
lui a été fourni à travers cet arrêt de service à vaisselle.
Donc, je peux maintenant tester pour voir si la variable vaisselle dans mon
MenuComponent reçoit réellement les valeurs correctement ou non.
Alors, en allant, laissez-moi créer un autre test ici.
Donc, je vais créer un test ici, Avec le it,
comme vous l'avez vu plus tôt, donc tout comme le précédent.
Ce deuxième test, je vais appeler que comme elle et
plats, Les articles devraient être 4,
parce que la constante de plats que nous avons déclaré dans
le fichier shared.plats a quatre plats dans la constante là.
Donc, quand ma variable vaisselle à l'intérieur de mon fichier MenuComponent ou
ts est initialisée en appelant le service de vaisselle.
Il aurait dû recevoir ces quatre plats et
s'est initialisé avec ces quatre plats.
Donc, je vais faire quelques tests sur cette variable de plats là.
Alors, comment puis-je accéder à la variable vaisselle ici ?
Donc, je dirais qu'il plats articles devraient être 4, et
alors je vais déclarer une fonction de flèche ici.
Et à l'intérieur de cette fonction de flèche, je vais spécifier
les différents tests que je vais effectuer.
Donc ici, je vais maintenant dire attendre (composant.,
et remarquez qu'il me donne automatiquement un accès
à cette propriété de vaisselle à partir du MenuComponent.
Donc, je peux dire que component.plats, puis je peux tester
pour voir que la longueur de ce tableau d'objets JavaScript devrait être.
C'est donc là que j'utilise la méthode ToBe de Jasmine ici.
Et puis je peux spécifier la valeur 4,
parce que je fournissais 4 plats dans mes plats constant
que j'ai déclaré dans le fichier shared.plats là-bas.
C'est donc le premier test que je vais faire,
cela devrait s'avérer vrai.
Sinon, la configuration n'a pas fonctionné correctement, donc
je sais que mon code ne fonctionne pas correctement.
Mais je sais avec certitude que ce test devrait fonctionner correctement.
Si vous voulez en être sûr,
sauvegardons les modifications et allons voir notre test en cours d'exécution.
En allant à ce terminal,
vous voyez que maintenant mon application est recompilée, et le test s'exécute.
Et remarquez tous les verts dans la fenêtre du terminal.
Il dit exécuté 1 de 2 succès, exécuté 2 de 2 succès.
Ce qui signifie que mes deux tests ont été couronnés de succès.
Si je regarde mon navigateur, de sorte que vous voyez que le MenuComponent,
les deux tests sont réussis.
Permettez-moi d'en créer quelques autres et
ajoutez-les à cet ensemble de deuxième groupe de tests que je crée là.
En allant au fichier menu_component_spec.ts, j'en ajouterai un de plus.
Je dirai que le composant attend.,
et je dirai des plats [1].
Rappelez-vous que le nom du premier plat était,
Donc c'est ce que je vais tester, les plats [1] .name.
C'est donc ainsi que je peux tester pour voir s'il reçoit les valeurs correctement.
Quelles sont les façons que je peux tester ?
Si je mets un point là, ça me donnera une suggestion de toutes les possibilités ici.
Donc, je dirai, je vais également utiliser à nouveau la méthode ToBe ici.
Et puis le deuxième nom du plat est,
Juste ça là, donc c'est le deuxième lanceur que je vais réaliser.
Donc, si mon code a fonctionné correctement, cela devrait également passer.
De même, permettez-moi d'en mettre un de plus ici.
Donc, je dirai attendre,
component.plats et je dirai 3.
Et ici, la propriété
en vedette devrait être Falsy.
Que vous soyez faux, ce n'est pas vrai dans ce cas, alors permettez-moi d'ajouter un autre.
Vous pouvez commencer à ajouter plus si vous le souhaitez,
jouez avec elle jusqu'à ce que vous soyez satisfait.
Alors faites ces ajouts. Laissez-moi enregistrer les modifications que j'ai faites
ici, allons voir si ce test fonctionne correctement.
Et en revenant à mon terminal, vous voyez que mon test est à nouveau en cours d'exécution.
Vous voyez que les deux tests ont été couronnés de succès,
maintenant je vais faire échouer une de ces choses.
Alors je vais entrer et changer ça en vérité.
Voir, c'est le plaisir de jouer avec du code.
Je vais changer cela en vérité et je sais que ce test va échouer.
Alors sauvegardons les modifications.
En regardant le terminal, vous voyez que le test a échoué.
Vous voyez tout ce rouge ici, ce qui signifie que le deuxième test n'a pas réussi correctement.
Et si vous faites défiler vers l'arrière, vous verrez ce test particulier échouer,
parce que quelque part là-bas, il dira que ce n'est pas le cas.
Ok, voyez cette déclaration ici il dit que faux attendu pour être véridique,
donc c'est pourquoi il a échoué.
Donc, ce n'était pas censé être vrai, mais j'ai dit que ça devrait être vrai, et
évidemment le test est faux, donc c'est pourquoi le test a échoué.
Donc, c'est ainsi que vous pouvez même tester pour voir si le test échoue,
si vous avez demandé les mauvaises choses aussi.
Mais encore une fois, permettez-moi de revenir en arrière et de corriger cela encore une fois.
Alors, revenant à mon fichier, je vais les changer
en falsy, parce que je veux que ce test fonctionne correctement.
Maintenant, nous ne sommes pas encore satisfaits.
Maintenant, dans ce test particulier, je teste seulement la variable vaisselle
qui est à l'intérieur de mon MenuComponent.
Comment puis-je jouer avec le modèle lui-même ?
C'est donc là que nous avons besoin de plus d'aide d'Angular.
Pour effectuer quelques tests sur le modèle, je vais entrer et
tirer quelques importations supplémentaires ici.
Alors, en allant à mon sommet de ce fichier, menu_component_spec.tsfile.
Je vais importer, Un
plus appelé By, qui est une méthode.
Vous me verrez utiliser ceci dans un court moment.
Cela doit être importé depuis, Angular,
/platform-browser.
Et aussi, je vais en importer un de plus qui est un élément de débogage.
L'élément debug me permet d'avoir accès au DOM afin
que je puisse effectuer des tests sur les éléments DOM directement.
Alors c'est là que je vais importer ceci de, le code angulaire ici, donc ces deux-là.
Alors ajoutez le By et le DebugElement aux importations, et
une fois que vous faites cela, nous descendrons dans le code ici.
Et puis nous allons ajouter dans un autre test où nous allons aller dans le DOM et
chercher un des éléments du doc.
Donc je le dirais, donc un test de plus ici,
qu'est-ce que ce test va faire ?
Pour ce test, je vais spécifier
le test comme devrait utiliser des plats dans le gabarit.
Je dis juste quelque chose au hasard ici,
parce que je veux juste vérifier que la variable vaisselle,
tout ce qu'elle rend disponible, est utilisée correctement dans le modèle.
Donc c'est la partie que je mets en place, et
puis la deuxième partie est la fonction flèche, et
dans cette fonction flèche, je vais fournir le code pour le prochain test.
Donc, à l'intérieur de cette fonction de flèche, ce que je vais faire
est que je vais d'abord appeler fixture et
puis détecter les changements.
Et puis après cela, je dirai laisser de :,
Est un DebugElement.
Grâce à cela, je vais avoir accès au DOM et
alors l'élément serait HTMLElement.
Donc, je veux avoir accès à l'un des HTMLElements de mon DOM.
Alors, quel élément je veux ?
Donc, pour ce faire, j'aurai accès au,
DebugElement en disant fixture et DebugElement.
Donc, cela me permet d'avoir accès aux éléments de mon DOM ici donc DebugElement.
Et puis je peux interroger et ensuite choisir seulement ceux qui seront d'intérêt pour moi.
Donc, je vais interroger et ensuite je vais demander en utilisant le By.
Alors remarquez où j'utilise le By que j'ai inclus en l'important.
Donc By, le By supporte un tas de mesures par lesquelles je peux
demander d'accéder à des éléments particuliers dans le DOM.
Donc, comme vous pouvez le voir, cela me dira ce que je peux importer et
alors le .css me permet d'avoir accès
pour faire correspondre les éléments par le sélecteur css donné.
Alors quel est le sélecteur css que je vais utiliser ?
Je sais qu'il y a un élément h1, un élément html dans le DOM et
que je vais avoir accès au premier élément h1 du DOM.
Et l'un des éléments h1 là-dedans est celui que
va afficher le nom de chaque plat là-bas.
Regardez en arrière et vous voyez qu'à l'intérieur de la grille chronologique en utilisant un h1 et
que h1 contient le nom du plat là.
Donc, je vais mettre la main sur cela et
puis je vais obtenir un élément et puis je dirais de,
de l'élément de débogage, puis je dirais nativeElement.
Et cela me donne accès à l'élément spécifiquement dans le DOM
auquel je fais référence et j'ai sélectionné en utilisant cette instruction plus tôt.
Donc, quand je interroge le DOM et puis dis, renvoyez-moi tous
ceux qui utilisent la balise h1 pour l'élément HTML.
Et j'ai accès à cela, et je peux interroger et
dire attendre (el.textContent).
Donc, je cherche le contenu à l'intérieur de ce h1 dans mon contenu fixe de modèle
et puis je dirai toContent.
Donc, c'est une autre méthode, toContient, c'est une méthode Jasmine appelée toContient.
Cela vérifie si cela contient une valeur particulière,
, puis je vérifierai les plats (0) .name.
Alors le premier plat est-il créé dans le DOM et ajouté dans le DOM ?
Si mon modèle fonctionne correctement, cela doit être présent dans le DOM.
Alors c'est ce que je vais vérifier pour voir si la grille correspondant à
le premier DISH a été créée et ajoutée dans le DOM ou non.
Alors je dis plats (0) .name, et dis en majuscules.
Rappelons que j'ai utilisé le tuyau en majuscules pour afficher le nom
du DISH en convertissant le nom du plat en
toutes les majuscules dans la tuile de grille dans le composant de menu.
Alors c'est ce que je vais vérifier, ok, donc je ne vérifie que pour
qu'un seul d'entre eux.
Vous pouvez effectuer beaucoup de ces tests, vous pouvez vérifier
plats (1) .name, puis plats (2) .name et plus si vous voulez.
Je ne fais qu'illustrer un exemple de la façon dont vous accéderiez aux éléments du DOM et
puis vérifierez ce qu'ils contiennent à l'intérieur.
Donc c'est un test que je vais effectuer ici, alors laissez-moi enregistrer les changements,
et voir si le test fonctionne correctement.
Allez dans ce terminal et quand le test s'exécute,
vous voyez que mon premier test a été réussi, le deuxième test a été réussi,
et le troisième test a également été réussi, merveilleux.
Maintenant, laissez-moi faire échouer le troisième test.
En allant dans le fichier menucomponentspec.ts,
Je vais supprimer ceci en majuscules, puis effectuer le même test.
Vous verrez que ce test échouera, enregistrez les modifications.
Et quand le test sera exécuté, vous verrez que le troisième test échouera.
Parce que je le fais échouer en vérifiant la mauvaise chose là-bas et
là vous allez, le troisième test a échoué ici.
Voici donc comment vous pouvez vérifier si certaines choses que
sont censées être là sont là correctement ou non.
Pourquoi est ce cas, donc vous pouvez voir ici, la raison pour laquelle ce test a échoué.
Il s'attend à ce que ce soit dans le DOM,
mais c'est ce qui est dans le DOM dans l'élément h1 dans le DOM.
C'est donc la raison pour laquelle le test a échoué ici.
Donc, en revenant, laissez-moi corriger l'erreur et
alors quand je réexécuterai le test, vous devriez maintenant voir que le test passe avec succès.
En revenant au terminal, vous verrez que lorsque ce test s'exécute maintenant, il fonctionnera correctement.
Et voilà, les trois tests sont passés par ma candidature.
Aussi, en regardant le navigateur, vous pouvez voir que les trois tests
ont été exécutés avec succès sur le fichier modèle de composants de menu et
aussi le composant de menu lui-même.
Maintenant évidemment, ce n'est pas nécessairement le test le plus complet mais
Je voulais juste vous donner une idée de la façon dont vous alliez
pour construire des tests dans votre application Angular.
Si vous vous faites emporter, vous pouvez aller dans tous les fichiers spec.ts que vous avez et
puis écrire votre propre test pour chacun de ces composants en utilisant les connaissances que vous avez acquises ici.
Aussi, vous pouvez en savoir plus sur les tests dans la documentation Angular et
puis apprendre plus de façons d'effectuer des tests sur votre application Angular.
Testing est un domaine à part entière donc si j'ai besoin de vous apprendre tout sur les tests
qui viendront tout un cours en soi pour Angular.
Et dans ce cours, je voulais juste vous donner une idée de la façon dont
vous allez effectuer des tests dans votre application Angular.
Et ceci est un exemple de la façon dont nous pouvons configurer et
effectuer un test unitaire sur l'un des composants de notre application Angular.
C'est le bon moment pour vous de faire un bon commentaire avec le test des composants du message.
[MUSIQUE]