I'm new to cypress and am trying to figure out how things work.
I have my own function (which calls a test controller server to reset the database). It returns a promise which completes when the DB have been successfully resetted.
function resetDatabase(){
// returns a promise for my REST api call.
}
My goal is to be able to execute it before all tests.
describe('Account test suite', function () {
// how can I call resetDb here and wait for the result
// before the tests below are invoked?
it('can log in', function () {
cy.visit(Cypress.config().testServerUrl + '/Account/Login/')
cy.get('[name="UserName"]').type("admin");
cy.get('[name="Password"]').type("123456");
cy.get('#login-button').click();
});
// .. and more test
})
How can I do that in cypress?
Update
I've tried
before(() => {
return resetDb(Cypress.config().apiServerUrl);
});
But then I get an warning saying:
Cypress detected that you returned a promise in a test, but also invoked one or more cy commands inside of that promise
I'm not invoking cy in resetDb().
Cypress have promises (Cypress.Promise), but they are not real promises, more like duck typing. In fact, Cypress isn't 100% compatible with real promises, they might, or might not, work.
Think of Cypress.Promise as a Task or an Action. They are executed sequentially with all other cypress commands.
To get your function into the Cypress pipeline you can use custom commands. The documentation doesn't state it, but you can return a Cypress.Promise from them.
Cypress.Commands.add('resetDb', function () {
var apiServerUrl = Cypress.config().apiServerUrl;
return new Cypress.Promise((resolve, reject) => {
httpRequest('PUT', apiServerUrl + "/api/test/reset/")
.then(function (data) {
resolve();
})
.catch(function (err) {
reject(err);
});
});
});
That command can then be executed from the test itself, or as in my case from before().
describe('Account', function () {
before(() => {
cy.resetDb();
});
it('can login', function () {
// test code
});
})
You can use cy.wrap( promise ), although there might still be a bug where it never times out (haven't tested).
Otherwise, you can use cy.then() (which is undocumented, can break in the future, and I'm def not doing any favors by promoting internal APIs):
cy.then(() => {
return myAsyncFunction();
});
You can use both of these commands at the top-level of spec like you'd use any command and it'll be enqueued into cypress command queue and executed in order.
But unlike cy.wrap (IIRC), cy.then() supports passing a callback, which means you can execute your async function at the time of the cy command being executed, not at the start of the spec (because expressions passed to cy commands evaluate immediately) --- that's what I'm doing in the example above.
I'm using Puppeteer and Jest to run some front end tests.
My tests look as follows:
describe("Profile Tab Exists and Clickable: /settings/user", () => {
test(`Assert that you can click the profile tab`, async () => {
await page.waitForSelector(PROFILE.TAB);
await page.click(PROFILE.TAB);
}, 30000);
});
Sometimes, when I run the tests, everything works as expectedly. Other times, I get an error:
Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.
at node_modules/jest-jasmine2/build/queue_runner.js:68:21 <br/>
at Timeout.callback [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:633:19)
This is strange because:
I specified the timeout to be 30000
Whether or not I get this error is seemingly very random
Why is this happening?
The timeout you specify here needs to be shorter than the default timeout.
The default timeout is 5000 and the framework by default is jasmine in case of jest. You can specify the timeout inside the test by adding
jest.setTimeout(30000);
But this would be specific to the test. Or you can set up the configuration file for the framework.
Configuring Jest
// jest.config.js
module.exports = {
// setupTestFrameworkScriptFile has been deprecated in
// favor of setupFilesAfterEnv in jest 24
setupFilesAfterEnv: ['./jest.setup.js']
}
// jest.setup.js
jest.setTimeout(30000)
See also these threads:
setTimeout per test #5055
Make jasmine.DEFAULT_TIMEOUT_INTERVAL configurable #652
P.S.: The misspelling setupFilesAfterEnv (i.e. setupFileAfterEnv) will also throw the same error.
It should call the async/await when it is async from test.
describe("Profile Tab Exists and Clickable: /settings/user", () => {
test(`Assert that you can click the profile tab`, async (done) => {
await page.waitForSelector(PROFILE.TAB);
await page.click(PROFILE.TAB);
done();
}, 30000);
});
The answer to this question has changed as Jest has evolved. Current answer (March 2019):
You can override the timeout of any individual test by adding a third parameter to the it. I.e., it('runs slow', () => {...}, 9999)
You can change the default using jest.setTimeout. To do this:
// Configuration
"setupFilesAfterEnv": [ // NOT setupFiles
"./src/jest/defaultTimeout.js"
],
and
// File: src/jest/defaultTimeout.js
/* Global jest */
jest.setTimeout(1000)
Like others have noted, and not directly related to this, done is not necessary with the async/await approach.
This is a relatively new update, but it is much more straight forward. If you are using Jest 24.9.0 or higher you can just add testTimeout to your config:
// in jest.config.js
module.exports = {
testTimeout: 30000
}
I would like to add (this is a bit long for a comment) that even with a timeout of 3000 my tests would still sometimes (randomly) fail with
Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.
Thanks to Tarun's great answer, I think the shortest way to fix a lot of tests is:
describe('Puppeteer tests', () => {
beforeEach(() => {
jest.setTimeout(10000);
});
test('Best Jest test fest', async () => {
// Blah
});
});
For Jest 24.9+, we just need to add --testTimeout on the command line:
--testTimeout= 10000 // Timeout of 10 seconds
The default timeout value is 5000 (5000 ms - 5 seconds). This will be applicable for all test cases.
Or if you want to give timeout to particular function only then you can use this syntax while declaring the test case.
test(name, fn, timeout)
Example
test('example', async () => {
}, 10000); // Timeout of 10 seconds (default is 5000 ms)
For Jest 24.9+, you can also set the timeout from the command line by adding --testTimeout.
Here's an excerpt from its documentation:
--testTimeout=<number>
Default timeout of a test in milliseconds. Default value: 5000.
Make sure to invoke done(); on callbacks or it simply won't pass the test.
beforeAll((done /* Call it or remove it */ ) => {
done(); // Calling it
});
It applies to all other functions that have a done() callback.
Yet another solution: set the timeout in the Jest configuration file, e.g.:
{ // ... other stuff here
"testTimeout": 90000
}
You can also get timeout errors based on silly typos. For example, this seemingly innocuous mistake:
describe('Something', () => {
it('Should do something', () => {
expect(1).toEqual(1)
})
it('Should do nothing', something_that_does_not_exist => {
expect(1).toEqual(1)
})
})
Produces the following error:
FAIL src/TestNothing.spec.js (5.427s)
● Something › Should do nothing
Timeout - Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.
at node_modules/jest-jasmine2/build/queue_runner.js:68:21
at Timeout.callback [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:678:19)
While the code sample posted doesn't suffer from this, it might be a cause of failures elsewhere. Also note that I'm not setting a timeout for anything anywhere - either here or in the configuration. The 5000 ms is just the default setting.
I recently ran into this issue for a different reason: I was running some tests synchronously using jest -i, and it would just timeout. For whatever reasoning, running the same tests using jest --runInBand (even though -i is meant to be an alias) doesn't time out.
test accepts a timeout argument. See https://jestjs.io/docs/api#testname-fn-timeout. Here is a sample:
async function wait(millis) {
console.log(`sleeping for ${millis} milliseconds`);
await new Promise(r => setTimeout(r, millis));
console.log("woke up");
}
test('function', async () => {
await wait(5000);
}, 70000);
Mar 14, 2022, Jest 27.5 documentation indicates a new process:
https://jestjs.io/docs/api#beforeallfn-timeout
Pass a second parameter to test with the number of msec before timeout. Works!
test('adds 1 + 2 to equal 3', () => {
expect(3).toBe(3);
},30000);
// In jest.setup.js
jest.setTimeout(30000)
If on Jest <= 23:
// In jest.config.js
module.exports = {
setupTestFrameworkScriptFile: './jest.setup.js'
}
If on Jest > 23:
// In jest.config.js
module.exports = {
setupFilesAfterEnv: ['./jest.setup.js']
}
The timeout problem occurs when either the network is slow or many network calls are made using await. These scenarios exceed the default timeout, i.e., 5000 ms. To avoid the timeout error, simply increase the timeout of globals that support a timeout. A list of globals and their signature can be found here.
For Jest 24.9
Turns out if your expect assertions are wrong, it can sometimes spit out the exceeded timeout error message.
I was able to figure this out by putting console.log() statements in my promise callback and saw the console.log() statements were getting ran in the jest output. Once I fixed my expect assertions, the timeout error went away and tests worked.
I spent way too long to figure this out and hope this helps whoever needs to read this.
In case someone doesn't fix the problem use methods above. I fixed mine by surrounding the async func by an arrow function. As in:
describe("Profile Tab Exists and Clickable: /settings/user", () => {
test(`Assert that you can click the profile tab`, (() => {
async () => {
await page.waitForSelector(PROFILE.TAB)
await page.click(PROFILE.TAB)
}
})(), 30000);
});
For the jest versions greater than 27, you can add useRealTimers on the top of your spec file.
Here is the snippet
import { shortProcess, longProcess } from '../../src/index';
jest.useRealTimers();
describe(`something`, function () {
it('should finish fine', async function () {
await shortProcess();
expect(1).toBe(1);
});
it('should fail with a timeout', async function () {
await longProcess();
expect(1).toBe(1);
});
it('should finish fine again', async function () {
jest.setTimeout(10 * 1000);
await longProcess();
expect(1).toBe(1);
}, 10000);
});
Find the github issue here on jest repository.
This probably won't be terribly helpful to most people visiting this page, but when I was getting this error it had nothing to do with Jest. One of my method calls was getting an empty object and a null exception while running locally. Once I added a null check, the failing tests and console log in question disappeared.
if(response !== null){
this.searchSubj.next(resp);
}
else {
return;
}
For those who are looking for an explanation about
jest --runInBand, you can go to the documentation.
Running Puppeteer in CI environments
GitHub - smooth-code/jest-puppeteer: Run your tests using Jest & Puppeteer
In my case, this error started appearing randomly and wouldn't go away even after setting a timeout of 30000. Simply ending the process in the terminal and rerunning the tests resolved the issue for me. I have also removed the timeout and tests are still passing again.
Dropping my 2 cents here, I had the same issue on dosen of jest unit test (not all of them) and I notice that all started after I added to jestSetup this polyfill for MutuationObservers:
if (!global.MutationObserver) {
global.MutationObserver = function MutationObserverFun(callback) {
this.observe = function(){};
this.disconnect = function(){};
this.trigger = (mockedMutationsList) => {
callback(mockedMutationsList, this);
};
};
}
Once I removed it test start working again correctly. Hope helps someone .
add this in your test, not much to explain
beforeEach(() => {
jest.useFakeTimers()
jest.setTimeout(100000)
})
afterEach(() => {
jest.clearAllTimers()
})
I'm striving to create a Gulp task that does nothing except calling a custom function. No, I have, no source files, and no, I have no destination files. I just want to call a custom function in a standalone task, so I can have other tasks depending on it.
For the love of me, I've checked Google and SO and I couldn't find an example. The closest I've come with is this
var through = require('through2');
gulp.task(
'my-custom-task',
function ()
{
return through.obj(
function write(chunk, enc, callback) {
// here is where the custom function is called
myCustomFunction('foo', 'bar');
callback(null, chunk);
}
);
}
);
Now this does call myCustomFunction, but when I run the task with gulp my-custom-task, I can see the task starting but not finishing.
[10:55:37] Starting 'clean:tmp'...
[10:55:37] Finished 'clean:tmp' after 46 ms
[10:55:37] Starting 'my-custom-task'...
How should I write my task correctly?
If you just want a task that runs some function, then just do that:
gulp.task('my-custom-task', function () {
myCustomFunction('foo', 'bar');
});
If your function does something asynchronously, it should call a callback at the end, so gulp is able to know when it’s done:
gulp.task('my-custom-task', function (callback) {
myCustomFunction('foo', 'bar', callback);
});
As for why your solution does not work, using through is a way to work with streams. You can use it to create handlers which you can .pipe() into gulp streams. Since you have nothing actually using gulp streams, there is no need for you to create a stream handler and/or use through here.
I'm new to Gulp (and not very comfortable with js).
When I use
gulp.task('sass', function () {
gulp
.src('myfile.scss')
.pipe(sourcemaps.init())
.pipe(sass(myoptions))
.pipe(sourcemaps.write('./'))
.pipe(gulp.dest('mypath'))
.pipe(browserSync.stream({match: '**/*.css'}));
});
compilation is made in a few ms
But When i use
gulp.task('sass', function () {
return gulp
...
});
it take several seconds to compile.
Can someone explain me why ?
Thanks.
Gulp uses orchestrator to execute the tasks. Your task returns a promise or a stream (in your case it's a stream), which is used for sequencing.
When you return nothing, the caller can't know that your task isn't finished, which has at least 2 impacts:
you may think it's finished (from the log) before it really is
following tasks may start too soon, and might even use an old version of the compiled CSS data
I have a standalone Node script called compile.js. It is sitting inside the main folder of a small Express app.
Sometimes I will run the compile.js script from the command line. In other scenarios, I want it to be executed by the Express app.
Both scripts load config data from the package.json. Compile.js does not export any methods at this time.
What is the best way to load up this file and execute it? I have looked at eval(), vm.RunInNewContext, and require, but not sure what is the right approach.
Thanks for any help!!
You can use a child process to run the script, and listen for exit and error events to know when the process is completed or errors out (which in some cases may result in the exit event not firing). This method has the advantage of working with any async script, even those that are not explicitly designed to be run as a child process, such as a third party script you would like to invoke. Example:
var childProcess = require('child_process');
function runScript(scriptPath, callback) {
// keep track of whether callback has been invoked to prevent multiple invocations
var invoked = false;
var process = childProcess.fork(scriptPath);
// listen for errors as they may prevent the exit event from firing
process.on('error', function (err) {
if (invoked) return;
invoked = true;
callback(err);
});
// execute the callback once the process has finished running
process.on('exit', function (code) {
if (invoked) return;
invoked = true;
var err = code === 0 ? null : new Error('exit code ' + code);
callback(err);
});
}
// Now we can run a script and invoke a callback when complete, e.g.
runScript('./some-script.js', function (err) {
if (err) throw err;
console.log('finished running some-script.js');
});
Note that if running third-party scripts in an environment where security issues may exist, it may be preferable to run the script in a sandboxed vm context.
Put this line in anywhere of the Node application.
require('child_process').fork('some_code.js'); //change the path depending on where the file is.
In some_code.js file
console.log('calling form parent process');
Forking a child process may be useful, see http://nodejs.org/api/child_process.html
From the example at link:
var cp = require('child_process');
var n = cp.fork(__dirname + '/sub.js');
n.on('message', function(m) {
console.log('PARENT got message:', m);
});
n.send({ hello: 'world' });
Now, the child process would go like... also from the example:
process.on('message', function(m) {
console.log('CHILD got message:', m);
});
process.send({ foo: 'bar' });
But to do simple tasks I think that creating a module that extends the events.EventEmitter class will do... http://nodejs.org/api/events.html