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:
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.
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 .
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.
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.
shouldsans étendre Object.prototype(il suffit d'appeler require('should').noConflict()et d'utiliser should.js comme une alternative expect.
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.
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.2J'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é. ]