Je veux tester le code JavaScript dans notre application Web. Nous utilisons la bibliothèque JQuery et .NET MVC. J'ai regardé ces réponses et Jqunit avait l'air bien, alors je l'ai essayé, juste pour réaliser que je vais devoir avoir à quasiment de recréer tous les balises pour chaque page que je souhaite tester.
Est-ce que je manque quelque chose? Existe-t-il des approches alternatives pour tester le code JS / JQuery? Notre balisage est parfois complexe et change radicalement à la suite d'appels AJAX.
Le mieux que je puisse penser, c'est essayer de coller notre application dans une iframe sur une page de test. Je n'ai pas encore essayé.
9 Réponses :
Si vous testez des fonctions / objets JavaScript, pourriez-je suggérer le composant de test de YUI.
http://developer.yahoo.com/yui/yuiteest/
Une configuration très similaire à Junit mais nécessite uniquement que vous incluez quelques fichiers JavaScript test. Il serait assez facile d'inclure cela dans votre page tout en mode test uniquement.
Merci! Je vais essayer cela dès que possible.
Test de votre application à l'intérieur d'un iframe pourrait fonctionner.
Ce que j'ai trouvé pour être mieux consiste à rester mieux avec le paradigme de présentateur de la vue modèle (MVP) (sur le côté du client seul), ainsi que de casser les composants de l'interface utilisateur dans des morceaux digestibles pour pouvoir tester chaque composant à l'intérieur de son propre page "pilote". La majeure partie de la logique réside dans le ou les présentateurs, qui est pure javascript et peut donc être testée avec des tests d'unités JavaScript pure. Les composants individuels de l'interface utilisateur peuvent être testés avec un cadre tel que sélénium et leurs tests garantiraient simplement qu'ils jettent les bons événements au présentateur. Le modèle peut également être effectué testable comme pure-JavaScript si la partie d'accès backend est stupéfiante / moquée dans une sorte de classe d'extrat-fetcher.
C'est tout à fait théorique. Y a-t-il un tutoriel / exemple? Et où est-ce que le balisage s'intègre lors du test "Chaque composant à l'intérieur de son propre" pilote "Page"? Cela signifie-t-il que je devrai séparer le balisage en morceaux pour chaque page? Je suppose que par "" Page "" Page "Vous voulez dire une page qui inclut le code de test JS et affiche les résultats du test.
Il peut être intéressant de considérer sélénium et d'exécuter des tests automatisés au niveau du navigateur.
Bien sûr, dans un monde idéal, vous travaillerez avec un cadre d'essais unitaires au niveau du code, mais étant donné que cela peut impliquer une reprise de nouveau recouvrement, un compromis solide pourrait être de tester que le JavaScript réellement Ce dont vous avez besoin pour utiliser le sélénium ou un cadre similaire.
La référence du navigateur Visibone suggère quelque chose qu'ils appellent «assertivité». Il donne essentiellement une suggestion sur la manière de mettre en œuvre des tests d'unité pour JavaScript. C'est vraiment assez simple.
voir le bas droit de la photo d'image suivante:
http://www.visibone.com/products/ebk8-9_850.jpg
Pour résumer ici:
Créer une fonction affirmée () : et vous pouvez appeler cela quelque chose comme ceci: ou éventuellement avec un meilleur === Comparaison: Il y a plus d'informations sur l'image liée et que vos fonctions d'affirmation pourraient devenir plus sophistiquées. J'ai fait une recherche Google sur "JavaScript ASSERT", et a eu plusieurs liens de retour, donc cela pourrait valoir la peine de vérifier vous-même.
Vous pouvez simplement créer la structure que vous souhaitez tester dans la mémoire sans l'ajouter au document. Cela ne fonctionnera pas tous les tests (comme par exemple les propérités CSS n'affecteront pas les éléments non insérés dans le document, mais dans certains cas, cela peut valoir la peine d'essayer).
Tout d'abord, c'est très vite, et deuxième que vous n'avez pas. T gâtez votre document avec des éléments de test dont vous avez besoin pour supprimer après avoir terminé les tests. P>
Voici cette idée dans un exemple très simple. P>
test('My tests', function () {
var testSubj = $('<div>This <b>is</b> my <span>test subject</span></div>');
ok(testSubj.children('span') == 'test subject', 'Span is correct');
});
Cela ne vaingerait-il pas au but d'essayer de tester le code avec un vrai balisage? Et si Markup change? Le test passera toujours et des problèmes potentiels passeront inaperçus.
Tout dépend de ce que vous testez. Comme je l'ai dit, vous ne serez pas en mesure de tester avec cette approche. Mais dans certains cas, il est plus facile d'aller de cette façon. Par exemple, si vous créez une structure compliquée dans une fonction et que vous souhaitez tester si c'est correct, il n'y a aucune raison de l'annoncer au document.
+1, cette approche fonctionne bien pour moi. Cela signifie structurer vos fonctions / classes à compter moins sur une structure DOM et recevoir les objets pertinents comme paramètres.
Vous avez peut-être besoin de deux approches, en fonction du code:
Vous voudrez peut-être déterminer comment vous pouvez restructurer votre code de telle sorte qu'il puisse être testé de cette manière. Pouvez-vous rendre le JS plus modulaire ou moins dépendant d'un certain balisage? (Malheureusement, parfois vous ne pouvez pas.)
L'inconvénient de ceux-ci est qu'ils ont tendance à être plus lents à courir et un peu plus difficile à maintenir ou à fragiles. Recherchez le modèle "Objet de la page" pour vous aider à sortir sur le front de la maintenabilité.
Nous finissons par automatiser les tests de l'unité JS à l'aide de sélénium pour le conduire.
En fait, vous pouvez rendre vos tests d'unité complètement indépendants du navigateur si vous le souhaitez. C'est beaucoup moins de travail pour se moquer de JQuery, voire des fonctions de navigateur que la plupart des gens pensent. En particulier envisager les simulacres seulement doivent soutenir le cas d'utilisation que vous testez réellement. Exécuter les informations à l'extérieur du navigateur en utilisant Rhino, V8 ou même un autre moteur JavaScript permet de réduire les risques que le navigateur interfère avec votre moqueur. Le bon endroit pour tester JQuery lui-même est dans un test d'intégration ou de régression. Mais les tests unitaires n'ont pas besoin de tester jQuery.
Pour le navigateur moqueur en dehors du navigateur, consultez Env.js. Tester à l'extérieur du navigateur avec Rhino et Env.js était un excellent moyen d'aller. Maintenant que les tests de navigateur ont évolué, il est assez facile de simplement exécuter des tests à l'intérieur de FF ou de Chrome et d'obtenir de bons rapports, alors je suis éloigné de cette configuration. Quoi qu'il en soit, les plugins JQuery Test Test fonctionnent bien, et je le recommande. Même pour les tests unitaires, je ne suis pas sûr de savoir pourquoi vous voudriez vous moquer de JQUERY car cela fonctionne bien dans ou hors du navigateur.
Vous pouvez utiliser un moteur Maintenant une fois que vous avez installé votre moteur de modèle, vous pouvez utiliser votre mise en page d'origine et ajouter un petit marqueur, où vous pouvez insérer une balise