I'm looking for a way that I can apply a little delay between each retires in mocha. I used the option "--retires", but it is getting executed without any delay. Is there any way that I can implement a delay between each mocha retry?
I tried using setTimeout() with a delay along the retries at test level. But I'm looking for something I can use globally, because I have more than 1000 tests in this suite
Im using mocha 8.1
Also is there any way that I can add a hook that runs on all my tests (it(test name)) and for all the test files
Thank you
you can use the Mocha configuration file.
At the project root, create the .mocharc.js file with your retry definitions.
module.exports = {
diff: true,
extension: ['js'],
package: './package.json',
reporter: 'spec',
slow: 75,
timeout: 15000,
retries: 20,
ui: 'bdd'
};
Related
I run Cypress from the terminal using an npm script. I would like to run a series of checks before any tests in any spec are executed (e.g. to ensure env variables are set as expected).
If any check fails, I'd like to log some debug info and Cypress to mark each spec as failed.
Is something like this possible without having to have a custom script that executes before Cypress is started?
I've played around with the support file, but logging to the terminal and failing all test specs seems problematic.
Yes you can use Before Run API
on('before:run', (details) => {
/* ... */
})
I have inherited a webdriver io - mocha test framework. Until now the tests have been ran one at a time. There was one test spec that had to be ran before the other. This was just handled in the file naming convention:
aFirstTest.js
xLastTest.js
So when the whole suite was ran, this ensured that aFirstTest.js was ran before xLastTest.js
I now want to run the tests in parallel mode.
How can I ensure that aFirstTest.js is ran before xLastTest.js?
This post might give you some ideas.
Otherwise, you'd need to present the specs to WebdriverIO as one. An easy way to do this would be wrapping them in another file.
wrapper.spec.js:
const first = require('./aFirstTest')
const last = require('./xLastTest')
And in your config:
suites: {
firstLast: [
'./specs/wrapper.spec.js'
]
}
I am using Ginkgo to execute some relatively long-running integration tests. Interspersed with my test output is the occasional warning that my tests are taking too long to execute:
• [SLOW TEST:30.000 seconds]
Is there a way to disable these warnings when running Ginkgo through the standard Go testing library? The documentation mentions a parameter (--slowSpecThreshold=TIME_IN_SECONDS) for the Ginkgo test runner, but doesn't seem to mention how to achieve the same programmatically.
Ginkgo handles its configuration in the github.com/onsi/ginkgo/config package, where the runtime configuration is available for modifications.
Making Ginkgo far more patient can be achieved with:
config.DefaultReporterConfig.SlowSpecThreshold = time.Hour.Seconds()
With Ginkgo v2, the config.DefaultReporterConfig variable has been deprecated (see also the migration guide) and cannot be used anymore to configure the "slow spec threshold".
To configure said threshold in Ginkgo v2, pass a types.ReporterConfig parameter into your RunSpecs call:
RunSpecs(t, "your test suite", types.ReporterConfig{
SlowSpecThreshold: 10 * time.Second,
})
I've been trying to use the mocha require option:
mocha mytest.js --require myglobals.js
But I don't know how to do it from karma. The idea is to run karma start and it will automatically require myglobals.js.
Is that possible to do it from within karma.conf.js or somehow else?
Maybe I'm not using karma/mocha in the right way.
My idea is:
I want to have unit/integration tests for both the client (react) and the server (node/express)
I want to just run karma start and both client and server tests are tested
I found very useful to have the following file pre-required, in order to avoid requiring some things in all tests:
myglobals.js:
const chai = require('chai');
// Load Chai assertions
global.expect = chai.expect;
global.assert = chai.assert;
chai.should();
// Load Sinon
global.sinon = require('sinon');
// Initialize Chai plugins
chai.use(require('sinon-chai'));
chai.use(require('chai-as-promised'));
chai.use(require('chai-things'));
For the server side I've made it work using the command:
mocha mytest.js --require myglobals.js
But still, I wanted to keep it running under the npm run test (which calls karma start) instead of creating another npm run test:server command.
Furthermore, I wanted to do the same on the client. I'm using webpack there as a preprocessor.
Any ideas if it is possible to accomplish that? Or maybe I'm in the wrong way?
Short Answer
Mocha in the browser does not support an equivalent of the --require option, but you do not need it. You can just load whatever you need ahead of your tests listing the files you want to load in files in front of your test files. Or if you use a loader like RequireJS, write a test-main.js that loads the modules you would load with --require first, and then load your test files.
Long Answer
If you look at Mocha's code you'll see that the only place --require is used is in the bin/_mocha file. This option is not passed further into the Mocha code but is immediately used to load the requested modules:
requires.forEach(function(mod) {
require(mod);
});
When you run Mocha in the browser, none of this code is run, and if you look in the rest of the Mocha code you won't find a similar facility anywhere else. Why?
Because it would serve no purpose. The --require option is very useful at the command line. Without it, the only way to load modules before Mocha loads the test files would be to either write custom code to start Mocha or put the necessary require calls at the start of every single test file.
In the browser, if you do not use a module loader, you can just load the code you'd load using --require by putting the script elements that load them in front of the script elements that load your tests. In Karma, this means putting these files earlier in the list of files you have in your karma.conf.js. Or if you use RequireJS, for instance, you write test-main.js so that the loading is done in two phases: one that loads the modules you'd load through --require on the command-line, and a second that loads your test files. It could be something like:
const allTestFiles = [];
const TEST_REGEXP = /test\/test.*\.js$/i;
Object.keys(window.__karma__.files).forEach((file) => {
if (TEST_REGEXP.test(file)) {
const normalizedTestModule = file.replace(/^\/base\/|\.js$/g, "");
allTestFiles.push(normalizedTestModule);
}
});
require.config({
baseUrl: "/base",
paths: {
...
},
});
// This guarantees that "a", "b", "c" loads before any other module
require(["a", "b", "c", ...], () => {
require(allTestFiles, window.__karma__.start);
});
I'm trying to convert a project from browserify+mochify to webpack.
The webpack docs demonstrate how to use mocha-loader to run the tests with webpack-dev-server, but assumes a single entry point into the tests.
All the existing tests were designed with mochify in mind which does not require a single entry point as it recursively bundles ./test/*.js.
The setup below sort of works for me. It still uses mochify to run the tests (because it has all the phantomjs interfacing), but doesn't rely on anything from browserify. If you run webpack --watch, it reruns all tests when a file changes.
webpack.config.js:
var path = require("path");
var child_process = require('child_process');
module.exports = {
entry: {
tests: "./tests.js"
},
output: {
filename: "tests.js", // Should be a unique name
path: "/tmp"
},
plugins: [
// Automatically run all tests when webpack is done
function () {
this.plugin("done", function (stats) {
child_process.execSync('mochify /tmp/tests.js', { stdio: 'inherit'});
});
}
],
};
tests.js:
// List all test dirs here if you have multiple
var contexts = [
require.context('./dir1/test', true, /\.js$/),
require.context('./dir2/test', true, /\.js$/)
];
contexts.forEach(function (context) {
context.keys().forEach(context);
});
Another approach is described here: https://stackoverflow.com/a/32386750/675011
This is not exactly an answer, but it solved the problem for me. The reason I wanted to combine mochify and webpack was that I wanted to use the browser console to debug my mocha tests. Since my mocha tests themselves don't rely on a browser, it was enough for me to finally realize I could use a node debugger and it would bring up the Chrome console, (almost) solving my problem. node-inspector is the node debugger, but I'm using babel, so I needed babel-node-debug, but that doesn't yet work with babel6, but there's an unmerged pull request that fixes it: https://github.com/CrabDude/babel-node-debug/pull/12.