Après avoir passé des heures, peut-être jours , en mettant la touche finale sur une nouvelle fonctionnalité impressionnante pour votre application Web, vous êtes enfin prêt à le voir en action. Vous ajoutez le nouveau code à votre base JavaScript, créez le candidat de la version et lancez votre navigateur, en vous attendant à être étonné. Ensuite, euh oh… la nouvelle fonctionnalité fonctionne peut-être bien, mais une autre partie critique de votre application - une partie que vous n'avez pas Touch pendant le développement de la nouvelle version - est devenue horriblement mal. Maintenant, vous êtes confronté au défi de revenir en arrière pendant les jours de travail pour essayer de comprendre comment vous avez brisé le code existant. Les jours heureux ne sont certainement pas ici.
Ce scénario même m'a mordu plus que je ne voudrais l'admettre. Et si vous codiez un certain temps, vous l'avez probablement également vu. Considérez, cependant, ce qui rend ce scénario si douloureux. Ce n'est pas vraiment parce que notre nouveau code a brisé le code existant; C’est inévitable dans le développement. La vraie douleur est qu'il a fallu si longtemps pour remarquer la rupture. Avec autant de développement puisque nous savions que notre application fonctionnait, il y a une grande quantité de code dans laquelle le bogue peut se cacher. Et, bien que cela puisse sembler un peu comme chasser une aiguille dans une botte de foin, nous n'avons pas d'autre choix que de le plonger.
Dans cet article, nous allons vraiment bannir ce scénario de notre développement JavaScript. Plus de fouilles pendant des heures, des jours ou des semaines de code à la recherche d'une aiguille. Le principe que nous adopterons est simple: trouver tout bug dès que nous le créons. C'est exact; Nous allons configurer un environnement de développement et un processus qui nous indique immédiatement lorsque nous écrivons du code qui introduit un bogue. De plus, l'effort supplémentaire que nous avons mis dans le processus ne sera pas gaspillé une fois le développement initial terminé. Le même code de test qui attrape nos bogues de développement sera complètement réutilisable dans un environnement d'intégration. Nous pouvons facilement intégrer les tests dans notre système de gestion de code source, bloquant les bogues avant même qu'ils puissent entrer dans notre base de code.
Dans les quatre sections qui suivent, nous allons d'abord examiner les outils dont nous avons besoin pour un environnement de test JavaScript. Nous allons ensuite considérer une application triviale, une application assez simple à comprendre, mais a toutes les fonctionnalités et fonctionnalités qui pourraient exister dans une application Web de production réelle. Les deux dernières sections montrent comment nous pouvons utiliser notre environnement pour tester l'exemple d'application pendant le développement et, une fois le développement initial terminé, pendant l'intégration.
Notre unité de test Nirvana nécessite des outils de développement qui ne sont peut-être pas encore dans votre établi. La nouvelle, bonne et mauvaise, est qu'il existe des options en abondance. C'est une bonne nouvelle car cela nous donne des options, et c'est une mauvaise nouvelle car le rythme du développement frontal signifie qu'il y a beaucoup trop d'options. Pour concentrer notre évaluation, soyons explicites sur nos deux principaux objectifs. Tout le reste est secondaire:
Pour le codage JavaScript, il n'y a pas de meilleur environnement de développement que le navigateur Web moderne. Que votre goût soit Firebug ou les outils de développeur de WebKit, le navigateur prend en charge l'inspection et l'édition DOM en direct, le débogage interactif complet et l'analyse des performances sophistiquées. Les navigateurs Web sont parfaits pour le développement, et nos outils de test et notre environnement doivent donc s'intégrer au développement du navigateur. Les navigateurs Web, cependant, ne sont pas si excellents pour les tests d'intégration. Les tests d'intégration sont souvent sur des serveurs quelque part dans le cloud (ou le moins quelque part dans le centre de données). Ces systèmes n'ont même pas d'interface utilisateur graphique, encore moins un navigateur Web moderne. Pour des tests d'intégration efficaces, nous avons besoin de scripts de ligne de commande simples et d'un environnement d'exécution JavaScript qui les prend en charge. Pour ces exigences, l'outil de choix est Node.js. Bien qu'il existe d'autres environnements JavaScript de la ligne de commande, aucun n'a l'étendue et la profondeur de la prise en charge pour correspondre à Node.js. Dans la phase d'intégration, nos outils de test doivent s'intégrer à Node.js.
Maintenant que nous avons établi que nos outils de test doivent prendre en charge les environnements Web Browser et Node.js, nous pouvons réduire suffisamment les choix pour sélectionner un cadre de test de base. De nombreux cadres de test JavaScript existent, mais la plupart sont fortement biaisés vers les tests de navigateur; Les faire fonctionner avec Node.js est généralement possible, mais nécessite souvent des hacks ou des ajustements inélégants. Un cadre qui ne souffre pas de ce problème est le moka, qui se décrit à juste titre comme:
Mocha est un cadre de test JavaScript riche en fonctionnalités fonctionnant sur le nœud et le navigateur, ce qui rend les tests asynchrones simples et amusants.
développé à l'origine pour Node.js, Mocha a également été étendu pour prendre en charge facilement les navigateurs Web. En utilisant Mocha comme cadre de test, nous pouvons écrire des tests qui prennent en charge le développement et l'intégration sans modification.
Contrairement à certains cadres de test JavaScript, Mocha a été conçu pour une flexibilité maximale. En conséquence, nous devrons choisir quelques pièces supplémentaires pour la terminer. En particulier, nous avons besoin d'une bibliothèque d'assurance JavaScript. Pour cela, nous compterons sur la bibliothèque Assertion Chai. Le chai est quelque peu unique en ce qu'il prend en charge tous les styles d'assertion communs - affirmer , attendre, et devrait. Les styles d'affirmation déterminent comment nous écrivons des tests dans notre test code. Sous les couvertures, ils sont tous équivalents; Il est facile de traduire les tests d'un style d'affirmation à l'autre. La principale différence de styles d'assurance est leur lisibilité. Le choix du style d'affirmation dépend principalement du style que vous (ou de votre équipe) trouvez le plus lisible et quel style produit les tests les plus compréhensibles. Pour voir la différence, envisagez de développer un test trivial pour le code suivant:
<span>var sum = 2 + 2;</span>
Un test traditionnel de style affirmation pourrait être écrit comme suit:
assert<span>.equal(sum, 4, "sum should equal 4");</span>
Ce test fait le travail, mais à moins que vous ne soyez habitué aux tests unitaires à l'ancienne, il est probablement un peu difficile de lire et d'interpréter. Un autre style d'affirmation utilise des attentes:
<span>expect(sum).to.equal(4);</span>
La plupart des développeurs trouvent des assertions de style attendu plus faciles à lire et à comprendre que les tests de style affirmer. La troisième alternative devrait, rend les affirmations de test encore plus comme un langage naturel:
sum<span>.should.equal(4);</span>
La bibliothèque Chai prend en charge les trois styles d'assurance. Dans cet article, nous nous en tiendrons.
La plupart des applications Web, y compris l'exemple trivial que nous considérerons dans cet article, s'appuient sur des bibliothèques et des services tiers. Dans de nombreux cas, le test de notre code nécessitera d'observer - ou même de contrôler - ces bibliothèques et services. La bibliothèque Sinon.js fournit de nombreux outils pour tester ces interactions. Ces outils se répartissent en trois classes générales:
avec la bibliothèque Sinon.js elle-même, nous pouvons augmenter la bibliothèque d'assurance Chai standard avec des affirmations sinon.js pour chai.
L'outil final pour notre travail de test est un environnement de développement pour les tests unitaires. Pour notre exemple, nous utiliserons Test’em. Test’em est une collection de scripts pratiques à configurer et à exécuter un environnement de test continu. Nous pourrions, si nous choisissons, écrire les scripts nous-mêmes et gérer l'environnement manuellement; Cependant, Toby Ho (Créateur de Test’em) a mis en place un package impressionnant qui peut nous éviter les ennuis.
Pour voir notre environnement de test en action, considérons une application simple. Bien que Pared à ses éléments essentiels nus, cette application comprend toutes les fonctionnalités requises pour une application réelle. (Le code source complet de l'application est disponible sur github.)
Les utilisateurs peuvent voir leur liste de Todos, et ils peuvent cliquer sur une case à cocher pour basculer n'importe quel statut de Todo.
Notre application commence par une table de base de données qui contient les informations de Todos. Voici le SQL que nous pourrions utiliser pour créer ce tableau.
<span>var sum = 2 + 2;</span>
Et voici comment le tableau pourrait s'occuper de nous y a mis des données de test.
Comme le montre le tableau, nos todos incluent uniquement une clé primaire (ID), un titre et un bit d'état pour indiquer s'ils sont complets ou non.
Notre application Web a besoin d'accéder à cette base de données, nous fournirons donc une interface de repos standard. L'API suit les conventions Ruby, mais peut être facilement implémentée par n'importe quelle technologie de serveur. En particulier:
Si vous n'aimez pas particulièrement Ruby, le code source comprend une implémentation PHP complète de cette API.
Notre application modeste est assez simple à implémenter en JavaScript pur sans bibliothèque, mais nous avons des plans bien plus importants. Nous pouvons commencer petit, mais finalement l'application comportera des fonctionnalités incroyables et une délicieuse interface utilisateur. En préparation de cette journée, nous allons s'appuyer sur un cadre qui peut soutenir notre application Ultimate Killer:
Maintenant que nous connaissons les composants qui comprendront notre application, nous pouvons définir le squelette HTML qui le soutiendra. Il n'y a rien de sophistiqué à ce sujet (encore), juste un document HTML5 minimal, des fichiers JavaScript et un petit peu de code pour démarrer les choses.
<span>var sum = 2 + 2;</span>
Maintenant que nous avons sélectionné nos outils et spécifié l'application, il est temps de commencer le développement. Notre première tâche consiste à installer les outils.
Même si nous nous développerons dans le navigateur, notre environnement de test repose sur Node.js. La toute première étape consiste donc à installer Node.js et le Node Package Manager (NPM). Il existe des binaires exécutables pour OS X, Windows, Linux et Sunos sur le site Web Node.js, ainsi qu'un code source pour d'autres systèmes d'exploitation. Après avoir exécuté l'installateur, vous pouvez vérifier à la fois Node.js et NPM à partir de la ligne de commande.
assert<span>.equal(sum, 4, "sum should equal 4");</span>
Tout ce dont nous avons besoin est commodément disponible en tant que package de nœud. Le gestionnaire de packages de nœuds peut gérer leur installation, ainsi que toutes les dépendances.
<span>expect(sum).to.equal(4);</span>
Le code source de cet exemple comprend une structure de projet complète avec les 15 fichiers suivants:
sum<span>.should.equal(4);</span>
Voici ce que contient chaque dossier et fichier:
Pendant le développement, nous ne sommes intéressés que par trois de ces fichiers, Testem.json, SRC / App-Todos.js et Test / App-Todos-Test.js.
La dernière étape avant le développement réel consiste à définir la configuration du test. Cette configuration réside dans le TESTEM.JSON à format JSON, et il est assez simple à créer dans n'importe quel éditeur de texte. Nous spécifions simplement que nous utilisons Mocha (Test’EM prend en charge plusieurs frameworks), et nous répertorions les fichiers JavaScript notre application et notre code de test nécessite.
<span>var sum = 2 + 2;</span>
Enfin, nous sommes prêts à coder. Dans un shell de commande, accédez au dossier racine de notre projet et exécutez le TymEm de commande. Les scripts de test s'exécuteront, effaceront la fenêtre du terminal et nous donnant une URL en haut à droite. Copiez et collez cette URL dans notre navigateur de choix et nous sommes partis.
Dès que nous lançons le navigateur Web, il exécutera automatiquement tous les tests que nous avons définis. Puisque nous commençons tout juste de développement, nous n'aurons aucun code, ni aucun cas de test. Le navigateur nous indiquera avec bonté cela.
La fenêtre du terminal à partir de laquelle nous avons lancé le test’em nous donnera également le statut.
Dans l'esprit d'un véritable développement axé sur les tests, nous commencerons par rédiger notre premier cas de test dans le fichier test / app-todos-test.js. Comme toute bonne application Web, nous voulons minimiser la pollution de l'espace de nom mondial. Pour ce faire, nous compterons sur une seule variable globale, TodoApp, pour contenir tout notre code. Notre premier cas de test s'assurera que la variable d'espace de nom global existe.
<span>var sum = 2 + 2;</span>
Comme vous pouvez le voir, nous avons besoin d'une déclaration préliminaire pour dire à Mocha que nous utilisons des assertions chai. Ensuite, nous pouvons commencer à écrire des tests. Par convention, les tests JavaScript sont organisés en blocs (qui peuvent être imbriqués en sous-blocs, etc.). Chaque bloc commence par un appel de fonction décrite () pour identifier la partie du code que nous testons. Dans ce cas, nous testons l'application globale, c'est donc le premier paramètre à décrire ().
Dans un bloc de test, nous documentons chaque cas de test par ce qu'il teste. C’est le but de la fonction it (). La façon de lire n'importe quel cas de test est de combiner les chaînes décrites () et it () en une seule déclaration. Notre premier cas de test est donc
L'application crée une variable globale pour l'espace de nom
Le code de test lui-même est à l'intérieur du bloc IT (). Notre cas de test est
assert<span>.equal(sum, 4, "sum should equal 4");</span>
Maintenant, nous avons un cas de test complet. Dès que nous enregistrons le fichier, Test'EM prend automatiquement le relais. Il remarque que l'un de nos fichiers a changé, il réduise donc immédiatement les tests. Sans surprise (puisque nous n'avons pas encore écrit de code pour l'application), notre premier test échoue.
La fenêtre du terminal se met également à jour automatiquement.
Pour faire passer le test, nous devons créer la variable d'espace de nom global. Nous passons au fichier srcapp-todos.js et ajoutons le code nécessaire.
<span>expect(sum).to.equal(4);</span>
Dès que nous enregistrons le fichier, Test'EM entre à nouveau dans l'action. Nous obtenons immédiatement des résultats mis à jour pour nos cas de test.
reculez un instant et réfléchissez à ce qui se passe! Chaque fois que nous apportons un changement, soit au code de test, soit à notre application, Test`em réinstalle immédiatement notre suite de tests. Tout ce que nous avons à faire est de garder le navigateur ou la fenêtre de terminal de Test’em visible dans un coin de notre écran, et nous pouvons voir la santé de notre code en temps réel, comme nous développons . Nous saurons dès que nous introduisons un bogue, même si le bogue se manifeste dans une partie du code différente de l'endroit où nous travaillons. Plus de creuser pendant les heures, les jours ou les semaines de nouveau code pour déterminer lorsque nous avons introduit un bug.
Avec notre environnement de développement désormais entièrement établi, nous pouvons commencer à développer l'application. Étant donné que notre application affiche une liste de Todos, il pourrait être bon de créer un modèle pour ces todos. Le modèle devra garder une trace à la fois du titre du TODO et de son statut. Ajoutons un test unitaire qui vérifie que nous pouvons créer un TODO avec des valeurs par défaut raisonnables.
<span>var sum = 2 + 2;</span>
Il existe plusieurs aspects de ces tests à noter.
Bien sûr, comme nous n'avons pas encore écrit le code modèle, tous nos tests échoueront. (Et nous le saurons immédiatement.) Mais une fois que nous aurons ajouté le code de notre modèle, les tests passent et nous sommes en route.
assert<span>.equal(sum, 4, "sum should equal 4");</span>
Maintenant que nous avons un modèle simple pour Todos, nous pouvons commencer à définir son comportement. Une chose que notre modèle devrait faire est de mettre à jour la base de données chaque fois que l'une de ses propriétés change. Dans un environnement de test unitaire, cependant, nous n'aurons pas de base de données réelle à vérifier. D'un autre côté, nous n'écrivons pas de code pour faire la mise à jour de la base de données. Au contraire, nous comptons sur l'épine dorsale pour gérer cette interaction. Cela suggère une stratégie de test unitaire pour ce cas de test. Tout ce que nous devons savoir, c'est que les modèles d'épine dorsale utilisent la méthode Save () pour mettre à jour le magasin de sauvegarde persistent le modèle. Dans notre cas, ce magasin de support est la base de données. Voici le code de test unitaire que nous pouvons utiliser:
<span>expect(sum).to.equal(4);</span>
Nous avons inclus un code supplémentaire avant chaque test, et nous avons ajouté une section de code à exécuter après chaque test. Ce code supplémentaire gère un stub Sinon, une fonction qui annule efficacement une autre fonction dans le code. Dans notre cas, le talon annule la méthode sauve () de ce.todo. Avec le talon en place, les appels à la méthode n'iront pas réellement à la bibliothèque BackNone. Au lieu de cela, Sinon intercepte ces appels et revient simplement immédiatement. Ce comportement est important. Si nous essayions d'exécuter la méthode réelle de Save Save () dans un environnement de test unitaire, l'appel échouerait car il n'y aurait pas de base de données ou d'API serveur disponible.
Avec le talon en place, nos cas de test peuvent l'utiliser pour vérifier le comportement du modèle. Dans le premier cas de test, nous avons immédiatement fixé le titre du TODO sur une nouvelle valeur. Étant donné que cela modifie la propriété Title, nous voulons que notre modèle mette à jour son magasin de sauvegarde. Pour vérifier que nous vérifions simplement que le talon a été appelé. Pour faire passer notre modèle à passer ces tests, nous pouvons rechercher des événements de changement et répondre de manière appropriée.
<span>var sum = 2 + 2;</span>
Bien sûr, notre application ne fera personne de bien s'il n'affiche pas réellement les Todos aux utilisateurs, et cela nécessite de créer du HTML. Nous utiliserons les vues de l'épine dorsale pour cette fonctionnalité. Dans notre application triviale, nous souhaitons simplement rendre chaque TODO en tant qu'élément de liste. Voici les cas de test qui nous permettra de démarrer.
assert<span>.equal(sum, 4, "sum should equal 4");</span>
Nous commençons nos tests de la vue avec deux cas de test. Nous nous assurons d'abord que la méthode Render () de la vue renvoie la vue elle-même. C’est une convention courante et très pratique dans l’épine dorsale car elle permet l’établissement de méthode. Notre deuxième cas de test vérifie que l'élément HTML créé par le rendu est un élément de liste (
<span>expect(sum).to.equal(4);</span>
Ensuite, nous pouvons développer le contenu détaillé de la vue de cette liste. Par exemple, nous voulons que l'élément de liste complet ressemble à ce qui suit.
sum<span>.should.equal(4);</span>
Pour nos cas de test, nous pouvons profiter de jQuery pour extraire les éléments individuels de l'élément principal de la vue.
CREATE TABLE `todos` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.', `title` varchar(256) NOT NULL DEFAULT '' COMMENT 'The text for the todo item.', `complete` bit(1) NOT NULL DEFAULT b'0' COMMENT 'Boolean indicating whether or not the item is complete.', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'
Notez que dans le dernier cas de test, nous avons coupé la méthode Save () du modèle. Étant donné que nous modifions une propriété de sa valeur par défaut, notre modèle essaiera consciencieusement de persister ce changement dans son magasin de soutien. Dans un environnement de test unitaire, cependant, nous n'aurons pas de base de données ou une API de serveur. Le stub remplace les composants manquants et permet aux tests de passer sans erreur. Pour faire passer ces tests, nous devrons ajouter un code supplémentaire à notre avis.
<span><span><!DOCTYPE html></span>
</span><span><span><span><html</span> lang<span>="en"</span>></span>
</span> <span><span><span><head</span>></span>
</span> <span><span><span><meta</span> charset<span>="utf-8"</span>></span>
</span> <span><span><span><title</span>></span><span><span></title</span>></span>
</span> <span><span><span></head</span>></span>
</span> <span><span><span><body</span>></span>
</span> <span><span><span><h1</span>></span>List of Todos<span><span></h1</span>></span>
</span>
<span><span><span><script</span> src<span>="lib/jquery-1.9.0.min.js"</span>></span><span><span></script</span>></span>
</span> <span><span><span><script</span> src<span>="lib/underscore-min.js"</span>></span><span><span></script</span>></span>
</span> <span><span><span><script</span> src<span>="lib/backbone-min.js"</span>></span><span><span></script</span>></span>
</span> <span><span><span><script</span> src<span>="src/app-todos.js"</span>></span><span><span></script</span>></span>
</span> <span><span><span><script</span>></span><span>
</span></span><span><span> <span>$(function () {
</span></span></span><span><span> <span>var todos = new todoApp<span>.Todos</span>();
</span></span></span><span><span> todos<span>.fetch();
</span></span></span><span><span> <span>var list = new todoApp<span>.TodosList</span>({collection: todos});
</span></span></span><span><span> <span>$("body").append(list.el);
</span></span></span><span><span> <span>})
</span></span></span><span><span> </span><span><span></script</span>></span>
</span> <span><span><span></body</span>></span>
</span><span><span><span></html</span>></span></span>Maintenant que nous avons vérifié que notre implémentation de la vue crée le bon balisage HTML, nous pouvons tester son interaction avec notre modèle. En particulier, nous voulons nous assurer que les utilisateurs peuvent basculer l'état d'un TODO en cliquant sur la case à cocher. Notre environnement de test ne nécessite pas un réel utilisateur humain, nous utiliserons donc jQuery pour générer l'événement de clic. Pour ce faire, cependant, nous devrons ajouter du contenu à un vrai Dom en direct. Ce contenu est connu sous le nom de test Fixture . Voici le code de test unitaire.
bash-3.2$ node --version v0.8.18 bash-3.2$ npm --version 1.2.2 bash-3.2$
Notez que nous entourons à nouveau la méthode Save () de ToDo. Sinon, Backbone essaiera de mettre à jour un magasin de sauvegarde inexistant lorsque nous modifierons le statut de TODO avec notre clic simulé.
Pour le cas de test lui-même, nous commençons par créer un élément
<span>var sum = 2 + 2;</span>
Dans la vue, nous voulons attraper des événements de clic sur l'élément
assert<span>.equal(sum, 4, "sum should equal 4");</span>
À ce stade, notre application est presque terminée. La seule fonctionnalité restante est de collecter tous les Todos ensemble. Naturellement, nous utiliserons une collection d'épine dorsale. Nous n'allons en fait rien faire de spécial avec notre collection, donc nous n'avons pas vraiment besoin de tests unitaires.
<span>expect(sum).to.equal(4);</span>
Nous pouvons cependant vérifier que notre implémentation de la vue de la collection est appropriée. Nous voulons que cette vue rendue comme une liste non ordonnée (
sum<span>.should.equal(4);</span>
L'implémentation de la vue est également simple. Il suit tous les ajouts à la collection et met à jour la vue. Pour le rendu initial (), il ajoute simplement tous les modèles de la collection un à la fois.
CREATE TABLE `todos` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.', `title` varchar(256) NOT NULL DEFAULT '' COMMENT 'The text for the todo item.', `complete` bit(1) NOT NULL DEFAULT b'0' COMMENT 'Boolean indicating whether or not the item is complete.', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'
Parce que notre API REST correspond parfaitement à l'API que prévoit, nous n'avons pas besoin de code personnalisé pour gérer l'interaction API. En conséquence, nous n'avons pas besoin de cas de test unitaire. Dans le monde réel, vous n'êtes peut-être pas aussi chanceux. Si votre API ne se conforme pas aux conventions de l'épine dorsale, vous devrez peut-être remplacer ou étendre une partie du code de la colonne vertébrale pour traiter l'API non standard. Ce code supplémentaire aura également besoin de tests unitaires. Heureusement, il est relativement facile de tester les interactions API, même dans un environnement de test unitaire.
Le moyen le plus simple de tester les interactions API repose sur la fonctionnalité de faux serveur de Sinon.js. Malheureusement, cette fonctionnalité est uniquement disponible (actuellement) dans la mise en œuvre du navigateur de Sinon. Il est explicitement exclu de l'implémentation Node.js. Il y a des hacks pour le faire fonctionner dans Node.js, mais ces hacks sont assez cassants et s'appuient sur les détails de l'implémentation interne. Il serait préférable de les éviter si possible. Heureusement, nous pouvons nous débrouiller sans le faux serveur de Sinon.
Le secret est de savoir que l'épine dorsale repose sur la fonction $ .ajax () de jQuery pour implémenter les API REST. Nous pouvons intercepter les interactions API en coulant cette fonction. Lorsque nous étouffer la fonction, nous voulons remplacer notre propre réponse. La méthode de rendement () du talon nous donne exactement cette opportunité. Il indique à Sinon quelle action supplémentaire cela devrait prendre lorsque le talon est appelé. Voici un cas de test complet pour vérifier que notre collection s'initialise correctement à l'aide de l'API REST.
<span>var sum = 2 + 2;</span>
Comme vous pouvez le voir sur la capture d'écran qui suit, nous avons maintenant un code écrit qui passe tous les cas de test unitaire. Pour le moment au moins, le développement est complet.
Maintenant que le développement côté client de notre application est terminé (et nous avons les tests pour le prouver), nous pouvons ranger notre JavaScript en toute sécurité dans un système de gestion de code source. Il peut ensuite être intégré au processus de construction de l'ensemble de l'application. Dans le cadre de ce processus, nous voulons exécuter tous les cas de test que nous avons développés. Cela garantira que le code qui compose le déploiement final réussit tous les tests que nous avons définis. Il protégera également contre les «ajustements mineurs» du code qui introduisent par inadvertance de nouveaux bogues.
Pendant le processus de construction, nous voulons probablement exécuter nos tests à partir de la ligne de commande plutôt que dans un navigateur Web. Nous n'avons pas besoin des détails des cas de test individuels, juste une assurance qu'ils passent tous. Node.js facilite la satisfaction de cette exigence. Nous avons seulement besoin de faire quelques petits ajouts à notre code source et aux fichiers de code de test unitaire.
Notre code a besoin de ces modifications car Node.js gère les variables globales différemment des navigateurs Web. Dans un navigateur Web, les variables JavaScript sont, par défaut, dans la portée globale. Node.js, en revanche, limite les variables à leur module local par défaut. Dans cet environnement, notre code ne pourra pas trouver les bibliothèques tierces dont il a besoin (jQuery, souligner et squelette. Si nous ajoutons les instructions suivantes au début, Node.js résoudra les références à ces bibliothèques de manière appropriée de manière appropriée .
assert<span>.equal(sum, 4, "sum should equal 4");</span>
<span>var sum = 2 + 2;</span>
La condition qui termine ces tests pour voir si nous exécutons dans l'environnement Node.js au lieu d'un navigateur Web. Dans un navigateur, les déclarations supplémentaires ne sont pas nécessaires, nous pouvons donc les sauter en toute sécurité.
Avec ces modifications, nous pouvons exécuter la suite de test complète à partir de la ligne de commande. Accédez simplement au dossier racine du projet et exécutez la commande moka. Le résultat semble assez familier.
Bien sûr, Mocha renvoie un niveau de sortie pour indiquer si tous les tests ont réussi ou non. Cela nous permet d'automatiser les tests dans le cadre d'un processus d'intégration continue, ou tout simplement en tant que script pré-Commiss local pour préserver notre propre santé mentale.
À ce stade, nous avons atteint nos objectifs. Nous avons un environnement de test unitaire qui s'exécute en arrière-plan pendant le développement et nous informe immédiatement lorsqu'un test échoue. Les tests s'exécutent dans un navigateur Web, nous donnant un accès complet aux outils de développement du navigateur pendant que nous codons. Les mêmes tests s'exécutent également aussi bien à partir d'un script de ligne de commande, nous pouvons donc automatiser leur exécution pendant le processus de construction ou d'intégration.
Voici les principales ressources de test unitaire utilisées dans l'article.
Backbone.js, comme d'autres frameworks JavaScript, prend en charge les tests unitaires pour assurer la qualité de l'application. Cependant, Backbone.js se démarque en raison de sa flexibilité et de sa simplicité. Cela ne dicte pas comment votre application doit être structurée, donnant aux développeurs la liberté de concevoir leurs applications comme bon leur semble. Cette flexibilité s'étend aux tests unitaires, permettant aux développeurs de choisir leurs outils et méthodologies de test préférés. De plus, Backbone.js a une empreinte plus petite par rapport aux autres cadres, ce qui le rend plus rapide et plus efficace pour les tests unitaires.
sont plusieurs outils disponibles pour les tests unitaires dans Backbone.js. Certains des plus populaires incluent le moka, le jasmin et la plaisanterie. Mocha est un cadre de test JavaScript riche en fonctionnalités qui fournit aux développeurs un moyen simple de tester leurs applications. Jasmine est un cadre de développement axé sur le comportement pour tester le code JavaScript. Il ne s'appuie pas sur les navigateurs, DOM ou tout cadre JavaScript, ce qui le rend idéal pour tester les applications Backbone.js. La plaisanterie, en revanche, est une solution de test complète en mettant l'accent sur la simplicité et la prise en charge des grandes applications Web.
Écriture d'unités Les tests pour les applications Backbone.js impliquent la création de cas de test pour chaque composant de l'application. Cela comprend des modèles, des vues et des collections. Chaque cas de test doit couvrir une fonctionnalité spécifique du composant et doit être indépendant des autres cas de test. Vous pouvez utiliser des frameworks de test comme Mocha ou Jasmine pour écrire vos tests. Ces cadres fournissent des fonctions pour définir les cas de test, configurer et démolir les environnements de test et faire des affirmations.
Exécution des tests unitaires dans le squelette. JS dépend du cadre de test que vous utilisez. Par exemple, si vous utilisez Mocha, vous pouvez exécuter vos tests à l'aide de l'outil de ligne de commande Mocha. Si vous utilisez Jasmine, vous pouvez exécuter vos tests à l'aide de l'outil de ligne de commande Jasmine. Ces outils offrent des options pour exécuter des cas de test individuels, des suites de tests entières ou tous les tests de votre application. Ils fournissent également des rapports détaillés sur les résultats des tests, y compris le nombre de tests passés, échoué et sauté.
Oui, vous pouvez Automatiser les tests unitaires dans Backbone.js. L'automatisation consiste à configurer un système d'intégration continue (CI) qui exécute automatiquement vos tests chaque fois que des modifications sont apportées au code. Cela garantit que tous les bogues introduits par les modifications sont capturés immédiatement. Il existe plusieurs outils CI disponibles, tels que Jenkins, Travis CI et Circleci, qui prennent en charge JavaScript et peuvent être utilisés pour automatiser les tests unitaires dans Backbone.js.
Certaines meilleures pratiques pour les tests unitaires dans Backbone.js incluent l'écriture de petits tests ciblés qui couvrent une seule fonctionnalité, en gardant des tests indépendants les uns des autres et tester tous les cas de bord possible. Il est également important d'écrire des tests avant d'écrire le code réel, une pratique connue sous le nom de développement axé sur les tests (TDD). Cela garantit que votre code est testable et vous aide à concevoir de meilleurs logiciels.
Le débogage des tests unitaires défaillants dans Backbone.js implique l'analyse du test Signaler pour identifier la cause de l'échec. La plupart des cadres de test fournissent des messages d'erreur détaillés qui peuvent vous aider à identifier le problème. Vous pouvez également utiliser des outils de débogage tels que Chrome Devtools ou Node.js Debugger pour parcourir votre code et inspecter les variables et les appels de fonction.
Comment puis-je améliorer les performances des tests unitaires dans Backbone.js?
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
gt540
js actualiser la page actuelle
git pull extrait le code
Comment acheter de vraies pièces Ripple
Comment résoudre le crash du Webstorm
Comparez les similitudes et les différences entre deux colonnes de données dans Excel
Comment éliminer le code HTML
Que sont les logiciels de programmation en langage C ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
