METTRE À JOUR. Voici un package simple que j'ai créé pour ajouter une configuration Karma minimale à n'importe quel projet avec une seule commande npm install min-karma.
Je voudrais clarifier certaines idées fausses possibles sur le karma et le rapporteur . La FAQ de Karma se réfère en fait à Adapter for Angular's Scenario Runner , qui, cependant, semble être abandonné, avec Protractor étant recommandé à la place.
Karma
Karma est un exécuteur de test qui exécutera les fichiers JavaScript spécifiés dans votre fichier de configuration explicitement ou à l'aide de node-globs . (Pour les modèles externes non JavaScript , le guide de test unitaire d'Angular recommande d'utiliser le préprocesseur html Karma pour les compiler d'abord en JavaScript.)
Il peut s'agir de tous vos fichiers source, certains d'entre eux, certains d'entre eux ainsi que des fichiers supplémentaires ou des fichiers non pertinents pour votre projet, ne fournissant qu'une configuration supplémentaire - vous l'appelez! Vous pouvez avoir plusieurs fichiers de configuration de karma à des fins différentes, que vous pouvez exécuter en parallèle ou un par un. Chaque processus de karma lance son propre ensemble de navigateurs (ceux-ci sont actuellement disponibles) .
Cette fonctionnalité de Karma permettant d'exécuter uniquement un ensemble de fichiers est ce qui le rend parfait pour les tests rapides exécutés en arrière-plan à chaque édition de fichier source, et obtenir un retour immédiat, ce qui est génial! Le seul point négatif est le rapport d'erreur "bruyant" qui, espérons-le, s'améliorera!
Karma n'est pas seulement pour les tests unitaires
Le test unitaire concerne une seule unité de votre code source. Dans le cas d'Angular, une unité typique est le composant angulaire ( Service, Factory, Provider, Controller, Filter, Directiveetc.). N'oubliez pas de garder votre Controllersmince, donc trop de tests unitaires pour ces derniers est un drapeau rouge .
Dans un test unitaire , toutes les autres unités de code dont dépend cette unité (ce que l'on appelle les dépendances d'unité) ne doivent pas être testées en même temps. Au lieu de cela, ils devraient être "moqués", par exemple remplacés par quelque chose de simple comme des instances factices. Angular fournit un excellent support d'environnement simulé . Idéalement, vous voulez voir toutes ces simulations directement dans vos tests, vous n'avez donc jamais besoin de vous demander d'où viennent toutes ces dépendances.
Karma est tout aussi utile pour les tests d'intégration , où un groupe d'unités de code source est testé ensemble, avec seulement certaines de leurs dépendances simulées. Il est important de se rappeler que toute dépendance est fournie par défaut à partir de vos modules de code source (tant que ces modules soit injectés directement dans vos tests , soit ils sont des dépendances d'autres modules injectés (auquel cas vous n'avez pas besoin de les injecter) , mais pas de mal à le faire.) Les dépendances simulées remplaceront celles fournies.
L'exécution rapide et fréquente est la principale caractéristique de Karma . Cela signifie que vous voulez éviter toute demande de serveur, toute requête de base de données, tout ce qui peut prendre plus de fractions de secondes. ( Sinon, ce ne sera PAS rapide! ) Ces longs processus sont ceux dont vous voulez vous moquer . Cela explique également pourquoi il est déconseillé de placer des services bruts de bas niveau comme $httpdirectement à l'intérieur de vos contrôleurs ou de toute unité de logique métier compliquée. En regroupant ces services de communication externes de bas niveau dans des services dédiés plus petits, il est beaucoup plus facile de «se moquer d'eux».
Ce que Karma ne fait pas, c'est d'exécuter votre site tel quel, c'est ce que sont les tests de bout en bout (E2E). En principe, vous pouvez utiliser les méthodes internes d'Angular pour recréer le site ou ses éléments. Ce qui, pour les petits morceaux, peut être utile, et un moyen rapide par exemple de tester des directives.
Ce n'est cependant pas un moyen recommandé de lancer du code compliqué dans vos tests. Plus vous le faites, plus vous risquez de faire des erreurs dans ce code au lieu de ce que vous testez réellement.
C'est pourquoi je n'aime pas personnellement la façon compliquée souvent mentionnée de tester des méthodes utilisant des méthodes de bas niveau comme $http. Il fonctionne plus propre pour isoler toute référence à des méthodes de bas niveau dans des méthodes dédiées de votre choix, dont la seule responsabilité est de faire des requêtes http. Ces méthodes dédiées devraient pouvoir fonctionner avec un vrai backend , pas un faux! Que vous pouvez facilement tester - manuellement ou même parfaitement avec Karma fonctionnant avec une autre configuration spéciale , tant que vous ne mélangez pas cette configuration avec celle habituellement utilisée pour exécuter Karmarégulier et rapide. Maintenant, après avoir testé vos petits services dédiés, vous pouvez vous en moquer en toute sécurité et facilement pour tester votre autre logique et intégrer ces tests dans votre configuration Karma habituelle .
Résumer. Utilisez Karma pour exécuter n'importe quel ensemble de fichiers JavaScript. C'est (devrait être) rapide. Vous ne voyez pas votre application complète, vous ne pouvez donc pas tester le résultat final de manière efficace et fiable. Est-ce que je le lancerais avec Protractor ? Pourquoi aurais-je? L'exécution de Protractor ralentirait mes tests, allant à l'encontre du but du Karma . Il est facile d'exécuter Protractor séparément.
Rapporteur
Le rapporteur est:
un framework de test de bout en bout pour les applications AngularJS. Protractor exécute des tests sur votre application exécutée dans un navigateur réel, interagissant avec lui comme le ferait un utilisateur.
Donc Protractor fait exactement ce que Karma ne fait pas - exécutez votre vraie application finale. Cela révèle à la fois sa puissance et ses limites:
L'exécution d'une application complète est le seul test final fiable que votre application fonctionne comme prévu. Vous pouvez rédiger des scénarios de user story complets et les intégrer à vos tests!
Mais il est plus difficile de suivre les erreurs sans isoler les unités individuelles de votre code source. C'est pourquoi vous avez toujours besoin de Karma pour tester d'abord votre code JavaScript.
Voudrais-je maintenant utiliser Protractor avec Karma ? Je peux sûrement les exécuter dans des fenêtres de terminal séparées, en parallèle. Je pourrais, en principe, leur faire partager des fichiers de test si nécessaire, mais normalement je préfère ne pas le faire. Pourquoi? Parce que je veux garder mes tests petits avec un seul objectif dédié.
La seule exception serait un fichier définissant des macros de test utiles pour les deux coureurs. Ceci, cependant, ne serait pas un fichier de test mais un fichier de définition de macro .
A part ça, j'aime une séparation claire entre mes tests. Ceux qui doivent être exécutés fréquemment et rapidement, et ceux de l'application complète. Cela fait une séparation claire entre l'utilisation de Karma et celle de Protractor .