I've built a single-page app off of chentsulin's electron/react boilerplate, which comes with the following node script for testing:
"test": "cross-env NODE_ENV=test BABEL_DISABLE_CACHE=1 mocha --compilers js:babel-register --recursive --require ./test/setup.js test/**/*.spec.js"
The boilerplate comes with a number of generic tests that are runnable at the outset (I confirmed this myself). It also comes with a number of webpack configs to suit different environments.
The app is fairly far along now, and is using electron-json-storage to handle local storage. I just went back to writing tests, and when I run the test node script (with or without --renderer) I get the following:
[dirpath]/node_modules/electron-json-storage/lib/utils.js:30
const app = electron.app || electron.remote.app;
^
TypeError: Cannot read property 'app' of undefined
I've tried using webpack.IgnorePlugin to ignore electron-json-storage, but that doesn't do anything. My guess is that electron-json-storage is trying to refer to an instantiated electron session that doesn't exist. What's the easiest way of dummying this up?
The problem was that I was using mocha (which came as part of the Electron-React boilerplate). Installing electron-mocha and changing the test script in the package.json resolved this problem immediately.
Related
I noticed that Vulan.js (one that implements package architecture) doesn't have tests. I tried to do it on my own, by adding practicalmeteor:mocha and adding Package.onTest to package.js that is in my package
Package.onTest(function(api) {
api.use([
'myapp:package-that-i-wanna-test',
'practicalmeteor:mocha',
'practicalmeteor:chai'
])
api.addFiles('somefile.test.js', 'server');
})
And then running meteor test-packages --driver-package practicalmeteor:mocha mypackage
Is it a right solution?
I've also tried running meteor test --driver-package=practicalmeteor:mocha, but got 0 tests even though I have them in my package named as *.test.js (so, it seems that this command does not look for test files in packages folder)
So, my question is what is the proper way of testing meteor app with Vulcan.js architecture and how should I perform running all tests in Vulcan.js
I've been starting to use create-react-app for my React projects, and as a testing library it comes with Jest.
As part of my React apps, I like to create integration tests (as well as unit tests) as I find it useful to be able to check the happy paths in the app are working as expected. For example: Render (mount) a page using Enzyme, but only mock out the http calls (using Sinon) so that the full React/Redux flow is exercised at once.
Before using create-react-app, I've used Mocha for testing, and I found mocha-steps to be a great extension for integration tests, as it allows tests in a group to be executed in sequence, and handles stopping if a step fails without stopping the entire test run.
Question: Is there any way to get Jest to behave in a similar way? Specifically, I'd like to be able to specify a series of tests in a group (such as in a describe) and have them execute sequentially in order.
I've been looking through the Jest docs, or for any other libraries that extend it, but I've come up empty. For now, it feels like the only option is to have one large test which makes me sad, and I'd prefer not to swap out Jest for Mocha if I can avoid it.
Thanks!
jest does not currently support flagging specific tests to be run serially (like ava's test.serial).
This has been requested before but I don't think they are working on it.
The workaround is for you to identify which test files are to be run concurrently and which ones are to be run serially.
For example, I usually name my unit tests with *.test.js and my integration tests with *.spec.js.
I can then run my unit tests concurrently.
$ jest '(/__tests__/.*\\.test)\\.js$'
And I can run my integration tests serially.
$ jest '(/__tests__/.*\\.spec)\\.ts$' --runInBand
I can combine the two in my package.json.
"scripts": {
"unit": "jest '(/__tests__/.*\\.test)\\.js$'",
"integration": "jest '(/__tests__/.*\\.spec)\\.ts$' --runInBand",
"test": "npm run unit && npm run integration"
}
Running npm test can then run concurrent tests first and then the serial ones next.
One of my co-workers added this Ava package to our setup, and it's done something I've never seen a Node package do before: interfere with other packages! Now when I try to run Mocha I get:
$ node_modules/mocha/bin/mocha test/
Test files must be run with the AVA CLI:
$ ava node_modules/mocha/bin/_mocha
I get that Ava would like to run my Mocha tests, but if I wanted that I'd run ava mocha not mocha. And because a co-worker is using it I can't simply uninstall the package.
Is there any way I can run plain Mocha tests on a machine with Ava installed?
One of the files in test/ imports ava and the imported code will recognise that it's not being run with the correct tooling and throw an error.
Might be worth subdividing your test/ directory to keep tests associated with their respective runners.
test/
ava/
SomeAvaTests.js
mocha/
SomeMochaTests.js
This way you can safely run mocha test/mocha/ and vice versa without worrying about treading on each other's toes.
This is a rough one. Two fellow developers and I have been working for nearly 24 hours on this. I have a conf.js that I can navigate to in Terminal and then run protractor conf.js (using the globally installed copy) and it runs perfectly. One at a time, each green dot appears after each successful test, and it takes about 80 seconds. Here's where it gets tricky.
If I force the local installation of Protractor to run by executing (path of project)/node_modules/protractor/bin/protractor conf.js then it fires up, shows me several green dots all at once, then throws an error about not being able to hook into angular. This is causing trouble with integrating with our build, since grunt looks for and uses the local copy of Protractor.
To further complicate matters, one of the two other developers can pull down my repo and run the local protractor installation on my conf.js no problem. It works 100%.
Error while waiting for Protractor to sync with the page: "window.angular is
undefined. This could be either because this is a non-angular page or because your
test involves client-side navigation, which can interfere with Protractor's
bootstrapping. See http://git.io/v4gXM for details"
We've checked all of the following:
Both local and global installations of Protractor are the same version, installed with npm.
Richards-MacBook-Pro:protractor richardpressler$ npm ls protractor
wear-test-web-framework#0.0.1
/path_to_project/wear-test-track0
└── protractor#3.1.1
Richards-MacBook-Pro:protractor richardpressler$ npm ls -g protractor
/usr/local/lib
└── protractor#3.1.1
Selenium is up-to date. We have run both (path to project)/node_modules/protractor/bin/webdriver-manager update as well as webdriver-manager update to update both local and global selenium server installations
I've tried firing up Selenium separately and then pointing Protractor to it so that I can see the output and it looks great when I run the conf.js using the global protractor (protractor conf.js), showing several [Executing] statements each followed by a [Done] statement. However, when I run the local protractor binary with (path to project)/node_modules/protractor/bin/protractor conf.js, I see that Protractor was able to connect to the Selenium instance, but didn't do much afterword:
When the protractor output looks like this:
Richards-MacBook-Pro:protractor richardpressler$ ../../node_modules/protractor/bin/protractor conf.js
Using the selenium server at http://127.0.0.1:4444/wd/hub
[launcher] Running 1 instances of WebDriver
Started
.......................
The Selenium server only outputs this:
10:35:47.612 INFO - Selenium Server is up and running
10:35:49.479 INFO - Executing: [new session: Capabilities [{count=1, browserName=chrome}]])
10:35:49.487 INFO - Creating a new session for Capabilities [{count=1, browserName=chrome}]
Starting ChromeDriver 2.21.371459 (36d3d07f660ff2bc1bf28a75d1cdabed0983e7c4) on port 34848
Only local connections are allowed.
10:35:50.516 INFO - Done: [new session: Capabilities [{count=1, browserName=chrome}]]
10:35:50.532 INFO - Executing: [set script timeout: 11000])
10:35:50.537 INFO - Done: [set script timeout: 11000]
Has anyone had similar misbehavior by Protractor when comparing the global, command-line version and the locally installed version in the project?
Thanks
Turns out all of the dependencies for protractor, grunt, selenium, etc. were in devDependencies so when I initially ran npm install it simply didn't install all of the sub-dependencies for those packages. If I move them into dependencies in the package.json, then re-run npm install, it works like a charm. Alternatively, running npm install --dev with those dependencies in devDependencies works fine too.
More info on the differences between dependencies, devDependencies, and peerDependencies can be found here: What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?
I'm developing a Node.js module, and I want to use Karma to auto-test it while working.
In my config file, I setup this:
// list of files / patterns to load in the browser
files: [
'./index.js',
'./test/indexSpecs.js'
],
Obviously, since Node.js isn't included in the browser files, I get this error:
Uncaught ReferenceError: require is not defined
If i add:
files: [
'./node_modules/**/*.js',
'./index.js',
'./test/indexSpecs.js'
],
I get a bunch of errors. I think js files get loaded in alphabetical order, which is wrong.
I also think that Node.js cannot be run in a browser, so what I'm trying to do may be totally wrong. Is there an alternative?
I'm developing a Node.js module, and I want to use Karma to auto-test
it while working.
You should not. Karma is designed for client-side code.
To auto-test your code, the simplest way is to create a npm script similar to this one (with mocha):
"scripts": {
"test": "mocha ./**",
"test:watch": "npm run test -- -w"
}
Then, use npm test to run the tests on demand, or npm run test:watch to continuously run the tests.
You can also use a grunt or gulp script with a watch task if you prefer.
You are right about karma not being a good fit for testing server side code. It is going to run everything in the context of a browser, which is causing the issues you are seeing. If you wanted to develop a module for the server and the client you could use karma in conjunction with browserfiy, but you would still need to run the tests in a node environment.
Instead, I would suggest using mocha: a simple and powerful test runner that works great for testing node modules.