Test Runner Runs Dog Slow

Hmm.. Normally it should take more or less the same time as when running in command line, as all WebStorm does is starting Mocha test runner, passing it arguments and displaying results as a tree view. Can you check how much time it takes to run the same tests using same command in system terminal?

when I run the tests from the console, it takes 1 second, it's fast.  When run the tests in Run mode in Webstorm it's fast.  When I run the tests in debug mode, it takes up to 30 seconds to even run the tests.

I'm using OS X Captain, Webstorm 11.0.3.

Also, here are my dependencies just in case you ask.

"engines": {
    "node": ">= 5.0",
    "npm": ">= 3.3.9"
  },
  "dependencies": {
    "babel-preset-react": "^6.5.0",
    "babelify": "^7.2.0",
    "express": "^4.13.4",
    "react": "^15.0.1",
    "react-dom": "^0.14.7",
    "react-router": "^2.2.4",
    "reactivate": "^1.5.8"
  },
  "devDependencies": {
    "babel-cli": "^6.5.1",
    "babel-core": "^6.7.4",
    "babel-preset-es2015": "^6.6.0",
    "babel-register": "^6.4.3",
    "browserify": "^13.0.0",
    "chai": "^3.5.0",
    "del": "^2.2.0",
    "eslint": "^2.10.1",
    "eslint-friendly-formatter": "^2.0.4",
    "gulp": "^3.9.1",
    "gulp-babel": "^6.1.2",
    "gulp-browserify": "^0.5.1",
    "gulp-develop-server": "^0.5.0",
    "gulp-eslint": "^2.0.0",
    "gulp-mocha": "^2.2.0",
    "gulp-mocha-phantomjs": "^0.11.0",
    "gulp-rename": "^1.2.2",
    "gulp-shell": "^0.5.2",
    "gulp-util": "^3.0.7",
    "gulp-wait": "0.0.2",
    "gulp-watch": "^4.3.5",
    "jquery": "^2.2.3",
    "jsdom": "^8.4.0",
    "less-plugin-clean-css": "^1.5.1",
    "mocha": "^2.4.5",
    "node-jsx": "^0.13.3",
    "react-addons-test-utils": "^15.0.1",
    "react-testutils-additions": "^15.0.0",
    "run-sequence": "^1.1.5",
    "vinyl-source-stream": "^1.1.0",
    "watchify": "^3.7.0"
  }
}

So, it's about debugging, not running? What Node.js version do you use?

the dependency info is above in the package.json (node version and more) and I gave the webstorm version I'm using.

If you wanna see it, here's a vid of it happening https://youtu.be/Ys5iqYARNPM?t=47.  Debug spins for a long time before it hits a debug point.

So, is it Node 5.*? Please see https://youtrack.jetbrains.com/issue/WEB-19117. It's actually Node V8 issue, but we've added  some fixes, they will be included in WS 2016.2. See https://youtrack.jetbrains.com/issue/WEB-16076#comment=27-981720 for possible workaround

OK going to the registry Webstorm | Help | Search for Registry and unchecking the js.debugger.v8.use.any.breakpoint works but I just wonder what that's taking away from me. If I wanted to use the V8 debugger I assume I am screwed until you deploy that fix.  So when is 2016.2 going to be deployed soon? 

thanks!

>I just wonder what that's taking away from me

as it's mentioned in https://youtrack.jetbrains.com/issue/WEB-16076#comment=27-981720, sourcemaps stop working if this option is enabled

>So when is 2016.2 going to be deployed soon? 

It is planned for Q3. You can try the EAP build (https://confluence.jetbrains.com/display/WI/WebStorm+EAP)

Well I'm not using source maps.  I'm running mocha config with the mocha option --compilers js:babel-core/register in my config.  So I'm not using any sourcemaps to test transpiled code.  I'm testing directly on the source files themselves and I assume it's transpiling on the fly in memory or something with the --compilers js:babel-core/register.  Notice my mocha config isn't even pointed to any transpiled files so there's no way I'm using sourcemaps here...unless you're referring to some other kind of source maps...please explain?

As you have your specs written in ES6 and transpiled to javascript with Babel, you ARE using sourcemaps - they are generated under the hood when using on-the-fly compilation. Sourcemaps is the ONLY way to get source files debugged in case if source files differ from the ones actually executed

gotcha...ok cool

I am having the same issue under Node v6 in PyCharm 5.0.5... Is the fix from WebStorm applied to PyCharm as well?

Yes, it should work in PyCharm as well

I've had this same issue while debugging Jest unit tests. Same exact behavior as described above: fast when run on CLI, fast when run w/ Webstorm, takes about 45s to "Instantiate tests" only when running the debugger w/ Webstorm. Can't seem to find any solutions.

I also have this issue with Jest (the “instantiating tests” step takes super long).

Here’s the test’s Run/Debug configuration: 
Here’s the full executed Jest command:

"C:\Program Files\nodejs\node.exe" --inspect-brk=60071 --require "C:\Program Files\JetBrains\IntelliJ IDEA 2017.3\plugins\JavaScriptLanguage\helpers\jest-intellij\lib\jest-intellij-stdin-fix.js" "C:\Users\iamak\OneDrive\Documents\Clients\DIRECTORY\node_modules\jest\bin\jest.js" --runInBand --colors --testResultsProcessor "C:\Program Files\JetBrains\IntelliJ IDEA 2017.3\plugins\JavaScriptLanguage\helpers\jest-intellij\lib\jest-intellij-test-results-processor.js" --testPathPattern "^C:\\Users\\iamak\\OneDrive\\Documents\\Clients\\DIRECTORY\\src\\routes\\api\\modifyCurrentUser\\test\.js$"

Here’s jest.config.js:

const path = require('path');

module.exports = {
    setupFiles: [path.resolve(__dirname, 'jestSetup.js')],
    rootDir: './src',
    forceExit: true,
};

Here’s jestSetup.js:

import 'babel-polyfill';
import 'dotenv/config';

may be related to https://youtrack.jetbrains.com/issue/WEB-28989. Do you have exception breakpoints enabled?

I'd say that debugging with `--inspect-brk` can be slow in large projects (as compared to `--inspect`) - this is a known issue (not actually specific to WebStorm). See https://youtrack.jetbrains.com/issue/WEB-27509

> may be related to https://youtrack.jetbrains.com/issue/WEB-28989. Do you have exception breakpoints enabled?

Yes, the "Toggle Break on Exception" option was turned on. Turning that off leads to expected (quick) test instantiation times. Thank you!