Quel est le meilleur cadre de test à utiliser avec Node.js? [fermé]


130

J'ai regardé la liste assez longue de frameworks de test sur https://github.com/ry/node/wiki/modules#testing . Quelle est l'expérience avec ces cadres?

Évidemment, la possibilité de fonctionner dans le navigateur serait un gros bonus, mais je suis principalement intéressé par Node.js. Quelque chose avec une inclinaison fortement asynchrone serait génial.

Réponses:


70

Mettre à jour:

Le moka est le meilleur à mon avis.


Quelle est l'expérience avec ces cadres?

J'ai joué avec expresso qui est un cadre de test assez cool qui a également une couverture de test. Il a été créé par TJ Holowaychuk, qui est également le créateur d' Express.js (cadre de développement Web JavaScript côté serveur incroyablement rapide (et petit) basé sur Node.js et Connect). J'ai récemment vu qu'il avait également une bibliothèque intéressante appelée should.js qui peut être utilisée avec Expresso pour une expérience de test encore meilleure.

De toute évidence, la possibilité de fonctionner dans le navigateur serait un gros bonus

Je ne pense pas qu'il puisse fonctionner dans le navigateur, mais je ne comprends pas non plus pourquoi vous voudriez l'exécuter dans le navigateur?

mais je suis principalement intéressé par Node.js. Quelque chose avec une inclinaison fortement asynchrone serait génial.

Citation de l'expresso:

L'argument passé à chaque rappel est beforeExit, qui est généralement utilisé pour affirmer que les rappels ont été appelés.

Vous pouvez utiliser beforeExit pour tester les fonctions asynchrones.


CONSEIL: Suivez TJ Holowaychuk sur GitHub , car il crée un très bon code open source.


Merci pour la réponse, j'ai essayé expresso mais j'ai trouvé que le support async n'était pas très intuitif. (Pour moi en tout cas)
doffm

3
J'essaie actuellement des vœux ( vowsjs.org ) qui étaient plus faciles à comprendre pour moi.
doffm

vowjs ressemblait également à un joli cadre de test. J'aime la fonction de couverture de test d'expresso. De plus, je me demande ce que vous n'avez pas compris?
Alfred

4
Vous dites que vous préférez Mocha maintenant, mais pourquoi?
Jonathan Arkell

Essayez-le. Mocha a tout :). Même prise en charge du navigateur, couverture du code. Vous l'appelez, le moka l'a!
Alfred

40

J'utilise VowsJS qui est un framework BDD asynchrone facile à utiliser (Behavior Driven Development) et fais le travail.

D'après ce que je vois ces derniers temps, c'est ce que beaucoup ont choisi de tester leurs modules NPM, donc je pense que jusqu'à présent, c'est l'un des meilleurs à utiliser.

Certains frameworks de test populaires qui pourraient être utilisés avec NodeJS sont également ceux:

Vous pouvez également voir une liste de frameworks de test JavaScript ici

Quelques bibliothèques supplémentaires qui pourraient vous aider à écrire un meilleur code sont celles-ci:

Il existe également Bamboo CI Server d' Atlassian qui automatise les builds et les tests. C'est un package pour Apache / Tomcat (qui sux car il utilise Java et cela le rend très lourd) n'est pas non plus gratuit mais il a une licence de démarrage qui coûte 10 $ donc je pense qu'il est abordable. C'est le serveur CI le plus en vedette que j'ai trouvé jusqu'à présent et il prend en charge tous les tests unitaires prenant en charge xUnit, ce qui signifie que vous pouvez exécuter des builds / tests pour n'importe quelle langue avec Bamboo.

Une autre option pour CI avec NodeJS est Travis que beaucoup de gens utilisent pour leurs projets open source, comme il est dit Un service d'intégration continue hébergé pour la communauté open source.

Il y a également une discussion de groupe Google avec le sujet Intégration continue pour les projets Node JS .


6
Une note pour les personnes qui envisagent d'utiliser Vows: il n'a pas été mis à jour depuis 2012
Code Commander

Ils ont fait quelques changements après . dernière sortie: sept. 2015
Andre Figueiredo

a une mauvaise passerelle sur le site officiel de Vows en 2020, peut-être mort?
Lincoln

wow, mon pote, cela fait BEAUCOUP d'années depuis, tout ce que je pouvais trouver sur VowJS maintenant est ceci: istavros.github.io/vowjs mais malheureusement, je ne peux pas vous suggérer de l'utiliser à 2020. Il est obsolète, et je le ferais fortement vous suggérons de vérifier Mocha ( mochajs.org ), Jasmin ( jasmine.github.io ) et Jest ( jestjs.io ) à la place.
panosru

14

Sur la base des commentaires du demandeur ci-dessus, j'ai essayé les vœux , et cela a résolu beaucoup de problèmes que j'avais avec mes tests asynchrones. Sa capacité à mélanger des tests série et parallèle est impressionnante.

Assurez-vous de lire attentivement le document d'orientation, mais une fois que vous l'avez compris, il est flexible, puissant et produit de beaux résultats nets.

MISE À JOUR: J'encourage également les gens à vérifier devraient pour leurs affirmations. Il permet des assertions très flexibles et très lisibles, et est compatible avec Expresso et Vows, et probablement la plupart des autres frameworks de test.

(Je publie ceci comme une réponse séparée juste au cas où les gens ne remarqueraient pas les commentaires sur la réponse d'Alfred.)

MISE À JOUR 1/7/2015: Pour ce que ça vaut, je suis depuis passé de Vows à Mocha, et de Should à Chai. Mocha a maintenant un bien meilleur support pour les tests asynchrones utilisant des promesses, et Chai permet plusieurs options d'assert flexibles, y compris l' expectapi, pour ceux qui n'aiment pas modifier le prototype d'objet.


1
shouldtacks une propriété non énumérable nommée shoulddans le Objectprototype, ce qui signifie que toutes les valeurs / objets que vous traitez ont un aspect légèrement différent au moment du test et au moment de la production. Bien que cela "fonctionne simplement" dans la plupart des cas, c'est en principe une mauvaise idée de modifier les prototypes intégrés; ne le faire que pendant le test semble mal. Tout a été fait uniquement pour qu'ils aient une belle syntaxe.
débit du

@flow depuis la v2, il est facile à utiliser shouldsans étendre Object.prototype(il suffit d'appeler require('should').noConflict()et d'utiliser should.js comme une alternative expect.
den bardadym

6

J'ai commencé à utiliser Jasmine pour mes tests JavaScript spécifiquement parce qu'il est petit et fonctionne à la fois dans le navigateur et dans le nœud. Il dispose également d'une API de reporting et de mise en correspondance très solide, ce qui facilite l'intégration avec d'autres outils à l'avenir. Avoir un cadre de simulation intégré est également utile car c'est souvent l'une des premières choses que j'ajouterais lorsque j'utilisais qunit pour TDD dans le navigateur.


2

Si vous voulez un véritable framework BDD, envisagez peut-être Yadda . Il s'intègre avec mocha, jasmine, nodeunit, qunit, zombie et casperjs, pour prendre en charge les fichiers de fonctionnalités, par exemple

   Scenario: provides the version of all services
      given service x is running
      and service y is running
      when I request the service versions
      then service x should be version 0.0.1
      and service y should be version 0.0.2

2

J'utilise nodeunit et sa capacité à travailler avec des fonctions asynchrones est assez simple.

Il y a une belle procédure pas à pas qui devrait vous préparer à utiliser nodeunit sur son blog .

[ Remarque: l'API a changé depuis la publication du blog - setUp(callback)et les tearDown(callback)deux prennent un rappel comme argument, que vous devez appeler lorsque votre configuration / démontage est terminé. ]


En regardant cela et après avoir essayé quelques tests des fonctions mongoose.js dans expresso, la préférence de nodeunit pour ne pas exécuter tous les tests en parallèle et autoriser les tests setUp et tearDown semble utile.
asparagino
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.