Applications de dorsale de test d'unité.js

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.

Les plats clés

• met l'accent sur la détection précoce des bogues pendant le développement pour éviter des problèmes complexes à des stades ultérieurs, garantissant une expérience de codage fluide et minimisant le retour en arrière.
• Utilisez le moka comme cadre de test de base en raison de sa compatibilité avec les environnements Browser et Node.js, permettant une transition transparente du développement aux tests d'intégration.
• Incorporez la bibliothèque Assertion Chai pour améliorer la lisibilité et la flexibilité des tests, offrant plusieurs styles (affirmer, attendre, devrait) qui répond à différentes préférences de développeur.
• Emploie Sinon.js pour créer des espions, des talons et des simulations, qui sont essentiels pour tester les interactions avec les bibliothèques et les services externes sans affecter leurs opérations.
• Configurez un environnement de test continu à l'aide du test’em pour exécuter automatiquement les tests lors des modifications de code, fournissant des commentaires immédiats sur la santé de l'application.
• Pendant le développement, concentrez-vous sur la création de tests unitaires détaillés pour les modèles, les vues et les collections pour garantir que chaque composant fonctionne correctement isolément.
• Transitionz en douceur aux tests d'intégration en adaptant les tests unitaires pour l'exécution de la ligne de commande avec Node.js, garantissant que l'application se comporte comme prévu dans l'environnement de production.

Assemblage d'un environnement de test JavaScript

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:

1. Notre environnement doit soutenir les tests continus sans friction pendant le développement.
2. Les tests créés pendant le développement doivent être également utilisables dans l'intégration.

Environnements d'exécution

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.

Framework de test

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.

Bibliothèque d'assertion

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.

espions, talons et simulations

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:

• espion . Code de test qui observe les appels aux fonctions en dehors du code testé. Les espions n'interfèrent pas avec le fonctionnement de ces fonctions externes; Ils enregistrent simplement la valeur d'invocation et de retour.
• Stub . Code de test qui représente les appels aux fonctions en dehors du code testé. Le code de stub ne tente pas de reproduire la fonction externe; Il empêche simplement les erreurs non résolues lorsque le code du test accède à la fonction externe.
• MOCK . Code de test qui imite les fonctions ou les services en dehors du code testé. Avec des simulations, le code de test peut spécifier les valeurs de retour de ces fonctions ou services afin qu'il puisse vérifier la réponse du code.

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.

un environnement de développement de test unitaire

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.

L'exemple d'application

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.

La base de données Todos

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.

id titre complet 1a échantillon d'élément TODO dans la base de données0 2 un autre échantillon TODO ITEM1 3 ans un autre échantillon TODO ITEM0

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.

Une API REST

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:

• Get API / Todos Renvoie un tableau codé par JSON de toutes les lignes de la base de données.
• Get API / TODOS / NNN Renvoie la représentation JSON du TODO avec ID égal à Nnn.
• API POST / TODOS Ajoute un nouveau TODO à la base de données à l'aide des informations codées JSON dans la demande.
• Put API / TODOS / NNN met à jour le TODO avec ID égal à NNN en utilisant les informations codées JSON dans la demande.
• Supprimer l'API / Todos / Nnn supprime le TODO avec ID égal à NNN de la base de données.

Si vous n'aimez pas particulièrement Ruby, le code source comprend une implémentation PHP complète de cette API.

bibliothèques JavaScript

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:

• jQuery pour la manipulation DOM, la gestion des événements et les communications du serveur.
• souligner.js pour améliorer la langue principale avec de nombreux services publics indeppensables.
• Backbone.js pour définir la structure de l'application en termes de modèles et de vues.

un squelette html

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>

tests pendant le développement

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.

Installation des 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>

Création de la structure du projet

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:

• todos.html: le fichier squelette html pour notre application, illustré en entier ci-dessus.
• testem.json: le fichier de configuration pour test’em; Nous examinerons cela en détail sous peu.
• API /: Un dossier pour notre implémentation API REST.
  • API / HTACCESS: Exemple de configuration pour le serveur Web Apache qui prend en charge notre API REST.
  • api / todos.php: code php pour implémenter l'API REST.
• lib /: un dossier pour les bibliothèques JavaScript utilisées par l'application elle-même et le framework de test.
  • lib / dorsalbone-min.js: version minifiée de Backbone.js.
  • lib / chai.js: bibliothèque d'assertion Chai.
  • lib / jQuery-1.9.0.min.js: version minifiée de jQuery.
  • lib / sinon-1.5.2.js: bibliothèque sinon.js.
  • lib / sinon-chai.js: sinon.js affirmations pour chai.
  • lib / sous-ore-min.js: version minifiée de sous-ore.js.
• mysql /: un dossier pour le code mysql pour l'application.
  • mysql / todos.sql: commandes mysql pour créer la base de données d'application.
• php-lib /: un dossier pour les bibliothèques PHP et la configuration de l'API REST de l'application.
  • PHP-lib / dbconfig.inc.php: configuration de la base de données PHP pour l'API REST.
• src /: un dossier pour notre code d'application côté client.
  • src / app-todos.js: notre application.
• test /: un dossier de code de test.
  • test / app-todos-test.js: code de test pour notre application.
  • test / moka.opts: options de configuration pour mocha; Nous examinerons cela dans la section suivante.

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.

Configuration du test’em

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>

commencer à développer

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.

un premier cas de test

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.

tester le modèle

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.

• Nous pouvons nidiquer des blocs de test les uns dans les autres. Un bloc de test contiendra tous les tests unitaires pour le modèle TODO, et un sous-bloc de ces tests se concentre sur l'initialisation.
• Dans un bloc de test, nous pouvons définir les fonctionnalités à exécuter avant chaque test. C’est le but du bloc AVANTEACH (). Dans l'exemple ci-dessus, nous créons une nouvelle instance d'un TODO avant chaque test.
• Le cadre Mocha s'assure automatiquement que le contexte JavaScript (c'est-à-dire la valeur de cela) est cohérent pour tous nos cas de test. C’est pourquoi nous pouvons définir ce.todo dans une fonction (le paramètre Beforeach ()) et le référencer en toute sécurité dans d’autres fonctions (tels que les paramètres it ()). Sans Mocha travaillant dans les coulisses pour fournir cette cohérence, JavaScript définirait différents contextes pour chaque fonction.

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>

en utilisant des talons pour les fonctionnalités tierces

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>

tester la vue

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 (

). Le code nécessaire pour passer ces tests est une vue de squelette simple.

<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>

Tester le modèle / afficher les interactions

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 avec un ID de luminaire et nous ajoutons cet élément à notre document en direct. Le document en direct, dans ce cas, est la page Web affichant les résultats de nos tests. Bien que nous supprimons l'élément immédiatement après la vérification du cas de test, nous définissons également sa propriété d'affichage sur aucune afin qu'elle n'interfère pas avec l'affichage de Mocha des résultats du test. Le code qui implémente cette fonctionnalité comprend un petit ajout au modèle TODO. L'ajout est une nouvelle méthode toggleStatus ().

<span>var sum = 2 + 2;</span>

Dans la vue, nous voulons attraper des événements de clic sur l'élément et appeler cette méthode pour le modèle.

assert<span>.equal(sum, 4, "sum should equal 4");</span>

tester la collection

À 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 (

). Les cas de test ne nécessitent aucune fonctionnalité que nous n'avons jamais vue auparavant.

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.'

Tests bonus: Vérification de l'API

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>

terminé!

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.

tests pendant l'intégration

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>

Nous devons également ajuster notre code de test. Les scripts de test ont besoin d'accéder à leurs propres bibliothèques (JQuery, Chai, Sinon.js et Sinon-Chai). De plus, nous devons ajouter un peu plus pour simuler le modèle d'objet de document d'un navigateur Web (DOM). Rappelons que nos tests pour la gestion des clics nous ont obligé à ajouter temporairement un «luminaire»

à la page Web. Node.js, bien sûr, n'a normalement pas de page Web. Le package de nœud JSDom, cependant, nous permet d'émuler un. Le code ci-dessous crée une page Web minimale et simulée pour nos tests.

<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.

Conclusion

À 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.

Ressources

Voici les principales ressources de test unitaire utilisées dans l'article.

• Environnement d'exécution JavaScript de ligne de commande: node.js
• JavaScript Unit Test Framework: Mocha
• Environnement de développement de test: test’em
• Bibliothèque d'assertion JavaScript: Chai Assertion Library
• espions, talons et simulations: sinon.js
• Affirmation supplémentaire: Sinon.js Assertions pour chai

Questions fréquemment posées (FAQ) sur les tests de test unitaires.

Quelle est l'importance des tests unitaires dans les applications Backbone.js?

Les tests unitaires sont un aspect crucial du développement de logiciels, en particulier dans les applications Backbone.js. Il s'agit de tester des composants individuels du logiciel pour s'assurer qu'ils fonctionnent comme prévu. Cela aide à identifier et à corriger les bogues au début du processus de développement, ce qui permet d'économiser du temps et des ressources. De plus, les tests unitaires facilitent le refactorisation du code, car les développeurs peuvent apporter des modifications au code et vérifier rapidement si les modifications ont brisé la fonctionnalité existante. Il améliore également la conception du code, car les tests d'écriture conduisent souvent à une meilleure modularisation et à une forte cohésion du code.

Comment les tests unitaires dans Backbone.js se comparent-ils à d'autres frameworks JavaScript?

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.

Quels outils puis-je utiliser pour les tests unitaires dans Backbone.js?

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.

Comment écrire des tests unitaires pour les applications de dorsalbone.js?

É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.

Comment exécuter les tests unitaires dans Backbone.js?

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é.

Puis-je automatiser les tests unitaires dans Backbone.js?

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.

Quelles sont les meilleures pratiques pour 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.

Comment puis-je déboguer les tests unitaires ratés dans Backbone.js?

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.

Puis-je utiliser des simulations et des talons dans le backbone de test d'unité. > Oui, vous pouvez utiliser des simulations et des talons dans le test d'unité Backbone.js. Les maquettes et les talons sont de faux objets qui simulent le comportement des objets réels. Ils sont utilisés pour isoler le composant testé à partir du reste du système. Cela rend les tests plus fiables et plus faciles à écrire. Il existe plusieurs bibliothèques disponibles, telles que Sinon.js, qui fournissent des fonctions pour créer et gérer les maquettes et les talons.

Comment puis-je améliorer les performances des tests unitaires dans Backbone.js?

Améliorer l'amélioration Les performances des tests unitaires dans Backbone.js impliquent l'optimisation de vos tests et de votre environnement de test. Cela comprend la rédaction de tests efficaces qui s'exécutent rapidement, l'exécution de tests en parallèle et l'utilisation d'un cadre de test rapide. Vous pouvez également utiliser des outils de profilage pour identifier les tests lents et les goulots d'étranglement dans votre processus de test.

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!