ce qui est le moins de résistance pour le débogage moka tests?

Modifier Nov 2016: Nœud a maintenant intégré dans le débogueur, vous pouvez commencer avec --inspect. Cette réponse explique: https://stackoverflow.com/a/39901169/30946.

Je suis en train de construire un moka test en coffeescript. À droite en haut de l'essai que j'ai:

require "../assets/js/theObject.coffee"
debugger
ss = new TheObject()

J'aimerais arrêter de ce débogueur en ligne parce que l'objet en theObject.coffee n'est pas en cours de chargement. Je suis l'aide d'un noeud-inspecteur et il fonctionne, sorta.

Le processus que j'ai, c'est:

nœud de départ-inspecteur
exécuter le test en ligne de commande avec mocha --compilers coffee:coffee-script ./test/theObjectTests.coffee --ui bdd -d --debug-brk
aller à la node-inspector, l'actualiser si il est déjà ouvert
attendez que le fichier theObject.coffee à charger, puis placer un point d'arrêt sur la ligne correcte

Il doit y avoir un moyen plus facile. Il semble que je devrais être en mesure d'avoir un débogueur en cours d'exécution et l'avoir juste arrêter de ce débogueur en ligne, mais je ne suis pas en mesure de trouver.

J'ai WebStorm, qui a un débogueur (cet article traite de mise en place pour exécuter moka tests, mais ça ne m'aide pas), mais quand je le démarre, il échoue. La commande qui est exécutée dans le WebStorm fenêtre de débogage est:

"C:\Program Files\nodejs\node.exe" --debug-brk=64232 C:\Users\jcollum\AppData\Roaming\npm\_mocha

C:\Users\jcollum\AppData\Roaming\npm\_mocha:2
basedir=`dirname "$0"`

Je soupçonne que peut-être un windows problème spécifique.

Env: Windows 7, Webstorm, nœud 0.8.16, moka 1.7.4, git-bash

La question: si vous êtes à partir de zéro avec Moka, quelle est la meilleure façon d'obtenir un débogueur va cela va s'arrêter sur un débogueur en ligne facilement? Facile est le mot clé ici.

Edit: car demandant ce que j'ai cessé de l'utiliser Windows et je travaille sous Ubuntu. Mon moka processus de débogage (que j'utilise rarement) est le même.

Voir ma réponse sur une question connexe de ce qui fonctionne pour moi: stackoverflow.com/a/29351654/3304034

InformationsquelleAutor jcollum | 2013-01-11

60

Édition, des années plus tard: le chemin le plus court dans le Nœud 6+ est: mocha --debug-brk --inspect ./test.js couplé avec le Nœud de l'Inspecteur Gestionnaire de plugin.

Plusieurs semaines plus tard, pas de réponses. Voici le chemin le plus rapide que j'ai trouvé.
1. écrire moka tests
2. installer node-inspector
3. commencer node-inspector -- il va maintenant être à l'écoute sur 5858
4. démarrer le moka test avec --debug-brk
5. à ce point, le moka le test est arrêté sur la première ligne
6. ouvrez un navigateur web et accédez à localhost:5858
7. (facultatif: ajouter un débogueur en ligne en haut de votre fichier de test, définir des points d'arrêt après il s'arrête dans ce fichier)
8. frapper la touche F10 pour obtenir le code d'aller
9. nœud-inspecteur va s'arrêter sur toute la ligne qui a debugger sur elle. Parfois, il ne bougera pas le code du fichier de la fenêtre à la bonne place, de sorte que vous aurez à frapper la touche F10 pour l'obtenir à l'étape à la ligne suivante et de montrer où c'est dans le fichier.
Ligne de commande:

node-inspector & mocha --compilers coffee:coffee-script/register ./test/appTests.coffee --ui bdd -d -g "should X then Y" --debug-brk
- c'est la meilleure que j'ai trouvé trop. Si jamais vous trouvez une meilleure façon veuillez mettre à jour cette réponse 🙂
- l'idée d'un test pour qu'il soit le plus granulaire, petit et facile à écrire que possible, de sorte qu'il est immédiatement évident que ce qui est la logique derrière le test. Si vous vous trouvez avoir besoin de déboguer vos tests vous faites du mal... période. Trouver un moyen de briser les tests en très petits morceaux, ou vous ne jamais finir de tester et tout ce que vous avez réussi à tester sera probablement trop peu fiable pour quiconque de dire que le logiciel est prêt pour la production.
- parfois moka n'est pas en panne, il se trouve juste là. Le débogage est utile pour ça. Vous êtes en supposant beaucoup de choses sur mon code sur la base de ma question.
- ne m'obtenez pas le mal "j". c'est juste ce que je crois à propos de comment les tests devraient être. Et oui la situation que vous avez décrite est familier pour moi, et devinez comment j'ai fait en sorte qu'il n'est pas le problème dans un test 🙂 pure simplicité. juste en le regardant (à noter, pas de débogage), il est devenu clair que c'était en fait l'application en cours d'essai, qui n'était pas le retour de la réponse résultant de moka tests assis là, à jamais. De mon expérience, je suis en plaidant pour le point: faire em facile et évitez de faire des tests pour vérifier que vos tests de tester
- Vous êtes à la description d'un test unitaire. Il existe plusieurs autres types de tests où le débogage est très pratique.
- même les petites et tests simples peuvent être mal interprétés - débogueur peut confirmer les attentes.
- de retour à mon point de vue et je me sens comme j'ai fait une bonne quantité de tests au travail, à la stand de mon point de vue... si le test peut être mal interprété, alors il est mal conçu tester.. c'est tout, il n'y a pas d'autre alternative... refonte de vos tests de telle manière qu'il n'y a absolument aucun doute sur ce qu'un seul cas de test est censé être le test.
- donc, si je suis en train de lire ceci correctement, dans un monde parfait, personne n'a besoin de débogueurs parce que tout le monde toujours TDDs tout, et ils le font tous "correctement". Je suis complètement d'accord. Eh bien, il est temps de retourner dans le monde réel, où j'essaie de passer quelques heures chaque jour!
- Bien sûr, lorsqu'un test échoue complètement et vous n'avez absolument aucune idée de ce code est de lancer l'erreur, il est utile d'être en mesure de lancer le débogueur, et de voir où l'exception s'est produite, même si c'est d'être pris. Et vous pouvez le faire avec, disons le Code de Visual Studio, seulement par la configuration du débogueur pour le lancement de Moka, et en sélectionnant "Toutes les Exceptions" ou "Les Exceptions" avant d'appuyer sur F5 pour démarrer. Je colle un "seul" sur les cas de test qui est erroring arrière, puis appuyez sur F5, et il me dépose à droite à la ligne d'erreur.
InformationsquelleAutor jcollum
11

En plus de @jcollum la réponse ci-dessus, j'ai trouvé au lieu d'utiliser l'option --debug-brk drapeau, il est préférable d'utiliser l'option --debug avec -w (veille)

De cette façon, lorsque vous ajoutez et supprimez débogueur les lignes de votre code, moka recharger les tests automatiquement et votre noeud-inspecteur s'arrête sur la ligne appropriée.

Cela évite d'avoir à revoir le terminal constamment de redémarrer les essais, puis inutilement de cliquer sur "continuer" dans le débogueur de franchir la première ligne de la source.
- J'ai eu de la difficulté à obtenir jcollums solution de travail dans OS X. La source et des fichiers de spec ne semblent pas être à la charge du nœud-inspecteur. Cela a fonctionné pour moi.
- Je reçois Error: Injection failed: no require in current frame. avec --debug. Même essayé avec --no-preload, mais encore faut appuyer sur Pause et Play.
InformationsquelleAutor captainclam
8

Avec les dernières versions de Moka et de node-inspector, cela a très bien fonctionné pour moi:
```
$ node-debug ./node_modules/mocha/bin/_mocha
```
Il charge le local Moka exécutable en tant que le processus débogué, s'arrêtant sur la première ligne pour mettre en place vos points d'arrêt.
- C'est la nappe, merci.
InformationsquelleAutor doingweb
6

Heads-up sur http://s-a.github.io/iron-node/. C'est plus un logiciel efficace pour déboguer rien Node.js liés à.

$ iron-node ./node_modules/mocha/bin/_mocha
- Pourriez-vous élaborer? Quoi de mieux avec ce vs nœud-inspecteur?
- juste quelques petites choses... ironNode prend en charge les thèmes. ironNode ne pas utiliser les WebSockets ou quelque chose comme ça. (Pas de perte de connexion des messages ou quelque chose comme ça). ironNode fonctionne indépendamment de nœud local de l'installation car il a son propre. Pas trop vite les scripts d'attacher le débogueur problèmes. Pas --debug-brk ou autre préparation nécessaire pour démarrer une session de débogage. Pas d'INTERFACE utilisateur dans une étrange états comportement. AUCUNE INTERFACE ne charge pas ou ne fonctionne pas et l'actualisation n'a pas aidé comportement Ne débogueur prend beaucoup de temps pour le démarrage de comportement. 🙂 il suffit de l'essayer. J'utilise exclusivement
- C'est tellement plus rapide pour moi que le nœud-inspecteur. Merci pour ce détachement.
InformationsquelleAutor Stephan Ahlf
5

La voie alternative à l'aide de WebStorm nœud débogueur.

En bref:
1. Vous avez besoin de WebStorm
2. Créer un nouveau Nœud de débogage profil de WebStorm
3. Définir le chemin d'accès à votre moka binaire en Path to Node App JS File
4. Ajouter des points d'arrêt et de démarrage de la session de WebStorm
Des instructions détaillées avec des captures d'écran par Glenn Bloc.
- J'ai essayé ce moment que j'ai fait Webstorm. Ne pouvais pas le faire fonctionner, a donné vers le haut. J'ai trouvé ce billet de blog il y a longtemps.
- Bizarre, je suppose que de la malchance. A travaillé comme un charme pour moi ces derniers temps, et j'ai vraiment aimé la façon dont il était facile de l'installation. Envisager de donner un plus à essayer 🙂
- En suivant les étapes dans le billet de blog a très bien fonctionné pour moi.
- Le blog désuet. J'ai eu plus de succès à regarder cet exemple de configuration: youtube.com/watch?v=4mKiGkokyx8&feature=youtu.être
InformationsquelleAutor Brock
3

Si c'est un Nœud de l'application, puis à l'aide intégrée Nœud débogueur en ligne de commande est le chemin le plus rapide vers la célébrité:
```
$ mocha $args -- debug
```
InformationsquelleAutor Filip Dupanović
1

Dans Webstorm maintenant, vous pouvez simplement mettre en place à l'aide d'un mocha de configuration. A fonctionné assez bien sortir de la boîte pour moi:
```
Node interpreter: /usr/local/bin/node
Working directory: /Users/me/sites/mysite
Mocha Package: /Users/me/sites/mysite/node_modules/mocha
```
et puis
```
All in directory
Test directory: /Users/me/sites/mysite/test
```
Il vous montre également les paramètres, il fonctionne avec de sorte que vous pouvez probablement les copier dans un autre environnement, si vous avez besoin de.
- l'arrêt à un point d'arrêt?
- Oui! @L'arbre on va s'arrêter là
InformationsquelleAutor timhc22
1

En ce qui concerne soit Webstorm ou PhpStorm, vous pouvez ajouter un spécifique moka configuration debug:

Vous aurez à ajouter via le vert, vous pouvez lui donner un nom.

Si déjà installé moka dans le projet via:
```
 npm install mocha --save
```
ou
```
 yarn add mocha
```
il va trouver la fonction de module dans votre projet.

J'ai dû fournir le chemin d'accès correct à mes tests unitaires, et de frapper la marque pour Include subdirectories/

Depuis mon projet est un texte tapé à la machine que j'ai eu à ajouter:
```
yarn add ts-node
```
Pour un pur js projet, il ne devrait pas être nécessaire.

Maintenant, vous pouvez exécuter le test complet costume, et vous pouvez alors choisir seul cas de test à partir de la liste et de les exécuter et déboguer sur leur propre.

InformationsquelleAutor k0pernikus
0

Aucune des réponses mentionnent le chemin de moindre résistance: Lorsque vous avez besoin de déboguer Moka tests, vous pouvez simplement ajouter une autre d'affirmer que vérifie la valeur que vous souhaitez déboguer.
```
myVar.should.equal(expected);
```
Je trouve que c'est souvent tout ce dont j'ai besoin. Et je viens de supprimer les assert(s) que j'ai utilisé pour le débogage quand je suis fait.

InformationsquelleAutor Cory House
0

Un moyen moderne de faire cela est d'utiliser nodejs est l'inspecteur de l'intégration de la fonctionnalité. Il est assez simple à utiliser. J'ai déjà écrit une explication détaillée de la façon de l'utiliser dans ce post
- Mise à jour de la question.
InformationsquelleAutor stropitek

Vous devez vous connecter pour publier un commentaire.