WebStorm + Jasmine + debug

[David Logan]

Hi

I'm having an interesting issue. I'm using WebStorm, the only usable IDE for writing systems in Javascript. I'm working on implementing the various testing frameworks.

If I run "meteor run" from a command line, it works great
If I RUN the app through WebStorm, it works great

However, if I DEBUG through WebStorm, it doesn't work at all. WebStorm fires up node_inspector on a port for debugging, but then jasmine (?) tries to do the same thing, and of course fails, because node_inspector fires up on the same port. This causes the tests to hang indefinitely. It of course also prevents me from debugging through the test code with my IDE.

Any ideas on how to make the test framework and the IDE both play nice together?

Thank you,
David Logan

[Gregg Van Hove]

It sounds like WebStorm is doing something different (or running a different command) when you DEBUG than when you RUN.

How are you including and running jasmine in your project?

-Gregg

--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jasmine-js+...@googlegroups.com.
To post to this group, send email to jasmi...@googlegroups.com.
Visit this group at http://groups.google.com/group/jasmine-js.
For more options, visit https://groups.google.com/d/optout.

[David Logan]

Hi Gregg

I'm not sure what you mean by doing something different. In WebStorm, all I do is click on the green bug to debug :) It's using all of the defaults, so I can't say with certainty what all WebStorm is doing on the backend. It's obvious though from the WebStorm console that it's firing up a node_inspector, using some random-looking port. Generally this is fine, and I am able to debug into my Meteor code just fine this way.

However, it's also obvious that Jasmine, through it's logs in .meteor/local/log, *also* tries to fire up a node_inspector on the same port as WebStorm has done. That's when everything goes south. The tests don't run, WebStorm doesn't debug, I get a bunch of lines in the jasmine log files about timing out processes and waiting another 1000ms, etc.

The problem seems to be that Jasmine (or mocha?) is trying to fire up a node_inspector in the background for its own purposes, which is fine as far as it goes, but it's somehow trying to use the same port that WebStorm is using to debug the main app, and they step on each other.

I'm happy to provide specifics if there is anything specifically you wish to know. I've gone ahead and attached the three standard jasmine logs as well as the output from the WebStorm debugging console. It doesn't say much, but it's obvious that the primary meteor run and it's mirrors are none too pleased that they all want attention from node_inspector.

I don't know if any other IDE actually supports javascript or native debugging, but I suspect if there are any more, we would all have this problem?

David Logan

[David Logan]

Sorry for the "binary files." meteor write the files ending in .log, so I assumed that would be easy, but it turns out the google view thinks it's binary. Apologies for that. In the future, I will rename them to TXT.

David Logan

[Gregg Van Hove]

Both of those jasmine logs say that `meteor` is the command actually being run, so this sounds more like an issue with meteor than jasmine.

On Thu, Jul 2, 2015 at 3:05 PM, David Logan <djlog...@gmail.com> wrote:

Sorry for the "binary files." meteor write the files ending in .log, so I assumed that would be easy, but it turns out the google view thinks it's binary. Apologies for that. In the future, I will rename them to TXT.

David Logan

[David Logan]

I'm obviously not disagreeing on that point, but I'm still not sure what to do. I can debug meteor code just fine in WebStorm without the jasmine framework. When I add in the jasmine framework, which tries to fire up a couple more instances of mirror apps for testing, it all hangs up, and I can't debug into the test code. This is extremely problematic, considering the fact that we are supposed to be writing behavioral tests and then make them work... :)

Is there a way, for example, to tell jasmine to have these mirrors start node_inspectors on different ports? I walked into the source code far enough to find the spots where it's firing up the processes, but it doesn't look like there is much I can tell jasmine in order to get it to modify the behavior of the mirrors.

David Logan

[David Logan]

I was looking up other information this morning, and happened to run across this, which sure sounds like the solution, but I can't figure out how to make it work either.

https://github.com/meteor-velocity/velocity/pull/298

[David Logan]

Upon further research, tests, etc., I finally hit upon a couple of points:

1.   Jasmine/velocity/mocha is in fact NOT using node_inspector to do any type of communication/checking between the mirror and anything else. I was under the impression that the node_inspector connection was an integral part of the framework. It's not.
2.   The IDE is firing up meteor in debug mode, and that just happens to propagate through to the velocity mirrors because the testing frameworks don't stop it. I suspect if I were to fire up meteor in debug mode from the command line, I would experience the same behavior.

On a semi-positive note, I can now set breakpoints and step through the test code by running meteor on the command line with the VELOCITY_DEBUG_MIRROR=jasmine-client-integration environment variable set. Semi-negative, because I can't just hit the debug button, and it takes *forever* for my IDE to connect remotely, but at least it works.

I will probably still try to figure out how to get velocity to stop firing it's mirrors up in debug mode though, and/or spend some more time trying to figure out if I can get it to really play nice with the IDE.