JavaScript : Les tests unitaires et fonctionnels

Comprendre les espions

Testez gratuitement nos 1324 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Les espions permettent de travailler avec les méthodes d'un objet et de vérifier qu'une méthode est bien appelée. Cela vous sera particulièrement utile avec un code qui exige d'autres appels pendant une fonction.
05:39

Transcription

On va essayer de comprendre ensemble les espions. Qu'est-ce qu'un espion ? L'espion, vous allez le câbler sur une propriété d'un objet donc généralement une fonction que vous allez avoir à appeler et vous allez pouvoir vérifier avec votre test que cette propriété est bien appelée, est bien levée à un moment ou un autre. Pour faire ça, on va être obligé de modifier notre code parce que ce qu'on avait avant, ce n'était pas un objet donc pas une classe particulière, ce n'est pas un object Javascript sur lequel on peut câbler des choses. C'était juste du code comme ça, dans un fichier. Voilà la modification qu'on va apporter. On va créer une variable chat qui va être égale à un objet, on va venir modifier le corps ici pour définir des propriétés et finir par virgule à chaque fois, une propriété say, une propriété addLineToChat, etc... jusqu'à la fin. On n'oublie pas de mettre des this pour faire les appels aux différentes fonctions. Ça semble être exactement la même chose sauf qu'ici on va avoir la possibilité de se câbler. Concrètement, on sait, nous, et on va vouloir savoir avec un espion que le rendu est bien effectué. Comment le sait-on ? On sait que, quand on fait un say, normalement il y a le rendu qui part. On veut que ce rendu soit effectué quand on ajoute une ligne say donc on va pouvoir le vérifier. Ce sont les espions qui vont nous permettre de câbler cette particularité. Ici, vous aurez un peu de modifications sur votre code dans l'interface puisqu'ici on aura juste à faire Chat avec une majuscule qui est le nom de notre objet. Pareil pour les specs, vous devrez modifier ces Chats avec une majuscule donc Chat.say et ici Chat.getSizeOfChat qui nous permettra de récupérer. On a vérifié que tout fonctionne bien, qu'il n'y a pas de problème, maintenant on va attaquer les espions. Ils se définissent comme ça, on va câbler un espion. Généralement on va essayer de le câbler beforeAll, ce serait mieux et comme ça beforeEach quand on va faire des choses on va pouvoir vérifier ensuite que l'espion a bien fonctionné. Pour le faire fonctionner, on appellera une propriété de l'objet, on dira soit toHaveBeenCalled soit toHaveBeenCalled plusieurs fois mais on a aussi la possibilité d'avoir des toHaveBeenCalledWith avec des valeurs particulières etc. Donc on peut aller très loin dans l'espionnage de nos différentes fonctionnalités. Nous allons implémenter un espion très simple. Avant tout beforeAll, ici. On va câbler une fonction et, à l'intérieur, on va ajouter un espion sur la propriété render. Pour cela, vous allez utiliser spyOn vous allez lui donner l'objet à espionner, qui est Chat et vous allez lui donner la propriété qui est render que l'on veut espionner. On sait maintenant que quand on va faire un Chat.say render va partir donc logiquement on doit pouvoir avec un nouveau it vérifier, ici, qu'on a bien un rendu qui a été effectué. Ici on va simplement mettre : le rendu est effectué. On va venir câbler, bien sûr, toHaveBeenCalled quelque chose de très simple à l'intérieur juste le fait de l'avoir appelé. Nous, ça va être Chat.render et on va mettre un toHaveBeenCalled On va ici faire jouer les tests et on va voir qu'on a un souci. Pourquoi ? Le toHaveBeenCalled passe mais c'est le 4 qui n'est plus égal, pourquoi ? Parce qu'ici c'est beforeEach donc un, deux, trois, quatre la collection est égale à quatre. On doit adapter un peu le test pour que ça fonctionne. Là, c'est bon, on sait que le rendu est effectué. On va vouloir vérifier aussi que le rendu est effectué un nombre de fois donc là un, deux, trois, quatre, cinq, on pourrait dire que le rendu va être appelé cinq fois. Donc toHaveBeenCalled cinq fois. On va ajouter un 5 ici et on va dire : est effectué à chaque ajout de ligne. On sait donc qu'à chaque ajout de ligne, on va voir un rendu. On va recharger et il va nous dire que non, il ne l'effectue que quatre fois, pourquoi ? Parce qu'au moment où il teste, ici, il n'est pas passé dedans pour faire le Chat.say donc, en fait, on est à quatre. Un, deux, trois, quatre, il faut vraiment vérifier ce qu'on est en train de faire. Avec quatre, ici, on va vous dire que maintenant c'est cinq... C'est embêtant alors on le remet à cinq. On va relancer, voyez qu'on va avoir un vrai problème parce que quand il le valide, pour lui il y en aura cinq et s'il ne le valide pas, il va être bloqué à quatre. On ne va pas savoir comment faire jouer celui-ci, il va être extrêmement embêtant mais, pourquoi pas, on pourrait se dire que ce n'est pas grave, je vais le déplacer en dessous, comme ça, ça va le valider, ça va être appelé quatre fois par exemple, car je sais que c'est quatre et je recharge. Oui, sauf qu'il n'y a pas de spy à cet endroit-là. Le spy est défini, ici, à cet endroit-ci. Dans notre cas actuel, on ne va pas pouvoir vérifier vraiment que c'est bien appelé autant de fois que souhaité parce qu'on utilise un beforEach qui est un peu particulier. Si on voulait vraiment vérifier avec un nombre de fois, regardez, je vais revenir en arrière, on n'aurait malheureusement pas d'autre choix que de faire ça, de venir rajouter, comme on avait fait au tout début, des appels à la main, ce qui fait que nous pourrions valider que notre structure comporte bien trois, parce qu'on n'en a fait que trois, que ça a bien été appelé trois fois parce qu'on a fait trois rendus. Là, on a la possibilité de le faire. Voyez que de temps en temps on n'a pas le choix, la répétition va être obligatoire, cela va dépendre de ce qu'on veut tester. Faites bien attention aux cas de tests et quand vous voyez que ça ne passe pas, que ça ne répond pas à ce que vous voulez faire, à ce moment-là, modifiez votre test en conséquence pour qu'il vérifie bien ce que vous demandez, précisément. Ici, on commence déjà à avoir un code source qui devient couvert, on dit couvert en test unitaire. On est en train de couvrir les cas de notre application, cela commence à devenir intéressant. Voilà, en tout cas, comment fonctionne un espion, on le câble et puis on essaye de vérifier si la fonction est bien appelée.

JavaScript : Les tests unitaires et fonctionnels

Réalisez des tests unitaires avec Jasmine et des tests fonctionnels avec CasperJS. Testez le code source et le rendu visuel de votre application, et optimisez vos développements.

1h54 (31 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Jasmine Jasmine 2.5
CasperJS CasperJS 1.1.4
Spécial abonnés
Date de parution :5 avr. 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !