I am getting an error message:
"C:\Program Files\nodejs\node.exe" C:\Users\keechan\Desktop\NodeJS\my-module\tests\sample.test.js
ReferenceError: describe is not defined
This issue only happens when I run via Run (ctrl+shift+F10).
When I run via the Debug Configuration I created, it works okay.
But considering if I have many test.js files and I want to be able to run each individual test suite, I do not want to have to make a debug configuration for each one of them.
I already tried:
installing #types/jest library under settings (Languages & Frameworks > JavaScript > Libraries)
added #types/jest as well as jest in my package.json
Also, I noticed that it is calling node.exe in:
"C:\Program Files\nodejs\node.exe" C:\Users\keechan\Desktop\NodeJS\my-module\tests\sample.test.js
Maybe this is the reason why? So how do I change it to use jest?
Thank you so much!
You are not running Jest, you run your spec file by passing it directly to Node.js using Node.js run configuration. Make sure to use Jest run configuration to start your spec
Related
I'm having issues with memory leaks coming from running my test suites with Jest where memory usage keeps growing with each suite.
After searching through the net, I've found that this could be related to a garbage-collector behaviour, and multiple Github threads suggest running this command:
node --expose-gc ./node_modules/jest/bin/jest.js --coverage --runInBand --logHeapUsage
The issue is that my project uses React (with CRA not ejected) and Typescript, so whenever I run this script it throws a Syntax error because of Typescript.
I've tried installing ts-jest library but it does not work. It may be related, but running the ts-jest setup init complains about already having a configuration due to CRA.
I've been searching and I have not found anything, since all related threads are about the known memory leaks Jest has, but none explain how to execute the node command with the expose-gc in a project with React and Typescript.
Is there any way I can expose the GC to the Jest script used by CRA so I can keep using the same configuration as until now?
Otherwise, how can I execute the node --expose-gc jest parsing my files so that it does not throw an error?
I'd also need to use the --inspect-brk to see where the leak comes from, so even if the --detect-leaks works, I still need to find a way to execute my Jest config from node command.
Thank you!
After reviewing the documentation from Jest, I've seen this section which suggests to run the debug configuration in VS Code calling react-scripts. After playing a little bit with it, this is the command that got it working:
node --inspect-brk node_modules/react-scripts/scripts/test.js --no-cache --env=jsdom --runInBand
As you can see, you have to call the test.js file inside react-scripts directly, and then you can send all the arguments you want to Jest, as you'd normally do when running tests directly from the terminal of your project.
If you execute this script:
node --inspect-brk node_modules/react-scripts/bin/react-scripts.js test --no-cache --env=jsdom --runInBand
You will be able to attach to the node debugger, but you won't be able to set debugger stops in your test files, as it will attach to the main process, which is react-scripts (and not the test script itself).
Hope this might help someone in a future!
Mocha is installed and runs fine through Terminal, Mocha Sidebar extension added in VS Code, however when using within VS Code it doesn't appear to find any tests within either a test folder I have set up, or a test folder I navigate to within VS Code
How do you alter the Mocha settings within VS Code to point it to a different/ correct location for the /test folder?
Is it possible to run tests on a folder you navigate to within VS code explorer and how to config that?
In the Output I am currently seeing the below:
Finding tests with Mocha on Node.js at "/usr/local/bin/node"
Running Mocha with Node.js at "/usr/local/bin/node"
No Mocha options are configured. You can set it under File > Preferences > Workspace Settings.
Test file(s):
undefined
I had this issue, and a couple of things solved it:
npm install -g glob
npm install -g mocha
npm install -g bluebird
Add "mocha.options": {} to the workspace configuration.
Add a glob option to the workspace configuration.
Restart VSCode.
Apparently not having global glob, mocha, and bluebird installed will cause it to fail on this.
I've updated my project to use node 6.11.3. When I now try to start a npm-script by using the Run-configurations provided from IntelliJ, I always receive the following error:
Error: Failed to replace env in config: ${NODE_EXE}
Important: This error appears only if I start npm from within my project. If I use the windows cmd, the error doesn't appear.
What could possibly have changed between node 6.11.2 and 6.11.3? Because with the prior version, everything worked fine.
A workaround for me is to add the NODE_EXE variable to my run configuration, but In my opinion, that shouldn't be needed, because it worked in 6.11.2 too.
Looks as if you have ${NODE_EXE} variable set in one of your npmrc files (see https://docs.npmjs.com/files/npmrc#files), and it can't be properly expanded for some reason when you run your script in the IDE.
is the issue specific to certain project?
how many npm versions do you have installed? Please check that npm chosen in Node.js Interpreters dialog is the same as you use in cmd shell?
please create an env.js file with console.log(process.env) and try running it via npm ("env" : "node env.js") in both cmd console and WebStorm - what is the result?
My goal is to run mocha unit tests by Atom, which is installed on Windows and also my src code resides. this should work independently from my Meteor App which is running on a different (Linux) machine.
Basically my setup is like this:
I have my repo and sourcecode:
c:\Users\Me\repos\meteor
My tests are inside:
c:\Users\Me\repos\meteor\tests
I have Node:
c:\Program Files\nodejs
installed with "npm i -g mocha --save-dev"
And i try to use this package https://github.com/Tabcorp/atom-mocha-test-runner but i can switch to another package if necessary.
What I've tried so far:
I edited my settings for the atom-mocha-test-runner:
Mocha command: C:\Program Files\nodejs\node_modules\mocha\.bin\mocha
Mocha command: C:\Program Files\nodejs\npm mocha
But each time i try to run my test via dropdown menu (Run Mocha Test), i get this error:
Mocha Test Results:
Node binary: C:\Program Files\nodejs\node.exe
Root folder: C:\Source\Repos
Mocha command: undefined
Path to mocha: mocha
Debug-Mode: false
Test file: tests\unit\first.js
Selected test: should return url
Failed to run Mocha
spawn mocha ENOENT
Anyone know what i miss or do wrong?
Still having no idea about why the package isn't working, I'm going to give a cop-out answer. If we figure out how to make it work, you can accept that answer instead. process-palette gives you the ability to run highly specific command-line instructions from Atom commands. Here's an example of a command that runs mocha in the project path for the current file with the same hotkey and also conveniently organized into its own menu item:
The disadvantage of this approach is that you have to know how to use the external program yourself. Packages like mocha-test-runner are designed to remove that need from the user, but as we can see here, sometimes the package doesn't know what it needs to be doing. The disadvantage is mitigated by the fact that you only have to learn the command for long enough to set up the configuration to run it, and from that point on it's very easy.
Advantages versus other packages include the ability to precisely control what's going on. Say you have multiple top-level folders in the current project, and they have different test suites. A package like mocha-test-runner can get the path from the active file, or from the project. If the developer chose to grab the project path, then you're going to have trouble running individual test suites. With the configuration I've shared, the command will always be run in the absolute path of the current file's project folder, so the tests will be run for whichever file you're working on at the time.
I run jasmine tests in my node.js application via grunt. I've added grunt test to Webstorm's run configurations.
In "Run/Debug Configurations" the "Grunt Test" has following properties specified: node interpreter (node.exe in Program Files), working directory (project location), JavaScript file (grunt binary), and application parameters (test - grunt task name).
The configuration works correctly but stops without printing full jasmine output. Sometimes before printing any output, most often after some part of jasmine log, but before test summary or error details. Always the last line of output is
Process finished with exit code 0
When I take the Webstorm command and run it manually in console it works fine and always prints full output:
"C:\Program Files\nodejs\node.exe" C:\...\node_modules\grunt-cli\bin\grunt test
My tests includes asynchronous cases, so it takes about 20 seconds to run them all.
I noticed that each attempt to run tests via Webstorm prints a bit longer output. First attempt ends without any but after ten further I got full output with test summary.
Known issue, please see http://youtrack.jetbrains.com/issue/WEB-1926 and discussion on stackoverflow (mocha + webstorm - error message broken)
To fix the case described in question we can run jasmine tests directly by jasmine-node command (skipping grunt).
We have to set up new "Run/Debug Configuration" based on "Node.js" pre-conf.
Node interpreter (as usual):
C:\Program Files\nodejs\node.exe
Working directory: project root,
JavaScript file:
node_modules\grunt-jasmine-node\node_modules\jasmine-node\lib\jasmine-node\cli.js
This is for my case (using grunt-jasmine-node). We can also provide path to cli.js of jasmine-node installed globally.
Application variables:
--verbose src/test/js
Of course the last one is a path to directory of tests in my project. Here we can specify list of files or use other jasmine-node commands and parameters.
The problem that process.exit() does not wait the stdout. You should defer the exit call with one tick, that's all.