I'm trying to run the node.js unit tests, on Windows. I can run them all using either vcbuild.bat test, or python ./tools/test.py. Either of those commands will run all available tests. I'm writing my own test and just want to run it. How can I run a specific test file, using test.py?
It ended up being as simple as running the file with the compiled node binary. Simply node path\to\test.js.
Related
We want to use Cucumber in our Node.JS project. It's probably a pretty basic question but I'm following the Cucumber tutorial and I'm getting stuck at the part where you have to run Cucumber in order to test if everything works. How do I run the new Cucumber (#cucumber/cucumber) package? I think that my issue is related to the package change, which is now /#cucumber/cucumber instead of just cucumber. The command ./node_modules/.bin/cucumber-js -f node_modules/cucumber-pretty doesn't work. Furtermore, what does -f means?
I have my testcafe test which is running well via terminal with
testcafe chrome jira-web-front\src\test\script\testcafe
I would like to be able to run it inside intelliJ js editor by clicking on the play button:
When I execute my test by clicking on the green play button I have:
I have some jest tests also in my project.
I tried to install intelliJ testcafe plugin but it didn't help.
Any idea about this?
Thanks
The logic currently used by JavaScript support plugin for detecting what test runner is available for a given test file is based on dependencies declarations in package.json nearest to this file: it looks for known test runners listed there and tries to run the most suitable one. As IDEA
doesn't provide any support for TestCafe (https://youtrack.jetbrains.com/issue/WEB-30315), you can't expect it to run TestCafe from a gutter; it runs your tests with jest because you have it in your dependencies list.
To run test using the run configuration provided by testcafe plugin, you need right-clicking the test in editor:
This plugin doesn't support running tests from gutter, neither it supports debugging.
Note that you can use VS Code recipes to debug TestCafe in IDEA. Namely, you need Node.js Run configuration like the following:
where JavaScript file: is set to a path to your locally installed testcafe module, e.g. node_modules\testcafe\bin\testcafe.js, and Application parameters: are testcafe cli args, like
chrome myTestFile.js
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'm working on a Go project that exposes a RESTful http API.
I want to run the Go project and use Nodejs (Mocha) to test the endpoints. It seems as if the nohup command doesn't keep running in the background.
Locally everything works but I don't seem to be able to get it running in Travis-ci.
language: go
go:
- 1.8
env:
- "PATH=/home/travis/gopath/bin:$PATH"
before_install:
- go get ./...
script:
- npm install mocha -g
- npm install
- nohup go run ./cmd/server/main.go --scheme=http --port=8080 --host=127.0.0.1 &
- mocha
First, you should seriously question whether writing tests in mocha makes sense. Admittedly, there might be cases when it does make sense (i.e. if you're porting a nodejs app to Go, and already have tests written for node). But even then, you should consider this a stop-gap measure, and write all new tests, and even migrate old tests, to Go as soon as possible.
But that aside, there's no reason you shouldn't be able to just start the process in the background normally. Perhaps with a shell script called from your Travis config (can often be cleaner and easier to follow than putting all commands in the config directly):
#!/bin/sh
go run &
mocha
If you really must run your tests in an external process, there are certain advantages from starting that from a Go test anyway. Namely, you can get test coverage stats, and starting can be more easily synchronized (so you don't need a sleep). To do this, you can follow my advice in this answer. Specifically, for the mocha case:
Write a test file that executes your main() function in a go routine:
func TestMainApp(t *testing.T) {
go main() // Or whatever you need to do to start the server process
cmd := exec.Command("mocha", ...)
cmd.Start()
}
But seriously. You should write your tests in Go.
Mocha runs directly after - nohup go run ./cmd/server/main.go --scheme=http --port=8080 --host=127.0.0.1 & so the server didn't start up yet.
Adding a sleep was enough.
script:
- npm install mocha -g
- npm install
- nohup go run ./cmd/server/main.go --scheme=http --port=8080 --host=127.0.0.1 &
- sleep 4
- mocha
But, the point is taken, I will move to Go tests :-P
I'm playing around with the Cordova hooks capabilities and I'm trying to test using a node application as a hook. In this article: http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/ it references running node applications, so I know it's possible.
I've created a simple node application that I'm using to test the before prepare and after prepare process:
#! /usr/bin/env node
console.log("this is a node module");
When I run my prepare, I get the following error:
C:\Users\jwargo\dev\lunchmenu>cordova prepare
The system cannot find the path specified.
Hook failed with error code 1: C:\Users\jwargo\dev\lunchmenu\hooks\before_prepare\test.js
I can't find any information anywhere about what an error code of 1 means here.
I've tested the node code and it runs fine with "node test.js" and when I execute test.js from the command line Windows simply launches my default editor.
So, can anyone tell me what I'm doing wrong or what I need to do to be able to execute a node application as a hook with the Cordova CLI?
Figured it out with some help from the Cordova dev team. The space in my shebang was causing the problem. I removed it and the problem went away.