I am mocking a function:
jest.mock('utils/downloadData')
In utils/download data I created a mock file:
export default {
general: jest.fn(() => {
console.log('mock fired')
}),
csv: jest.fn(() => {
console.log('mock fired')
}),
}
This function is being called inside a function I am testing:
...
const convertToCsv = () => {
downloadData.csv(CSV.stringify(csvData), fileName)
onFinish()
}
...
When debugging I see that the mock function is correctly set in the closure, when debugging step by step I see that the code reaches inside the mocked function and that console logs the message. Yet this test fails:
expect(downloadData.csv).toBeCalledTimes(1)
Jest accepts downloadData.csv inside the expect so I believe it sees the mocked function.
How is it possible that it doesn't register it as being called?
The tested function involved an async data fetching, which was mocked too. But the asynchronous nature of that caused the test to evaluate expected values before it finished running the tested function.
What helped was not just making the test function asynchronous (test('output', async() => {) but also including this line above the evaluation:
await new Promise(process.nextTick)
This allows the test to finish the asynchronous bits before evaluating the results.
I am trying to write tests for electron using spectron.
This is my code.
describe ('Application launch', function(done) {
this.timeout(30000);
const app = new Application({
path: electronBinary,
args: [baseDir],
});
before(() => app.start());
after(() => app.stop());
it('shows an initial window', async () => {
await app.client.waitUntilWindowLoaded();
const count = await app.client.getwindowcount();
assert.equal(count,1);
});
});
However, When I run npm test The error I get is
1) Application launch "before all" hook:
Error: Timeout of 30000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
2) Application launch "after all" hook:
Error: Application not running
at Application.stop (node_modules\spectron\lib\application.js:58:48)
at Context.after (test\spec.js:19:19)
Do I need to add any functions to the existing hooks?
It appears to be happening in your before all method. Notice that your error says 1) Application launch "before all" hook:.
So your actual test function looks fine to me. And I don't see a beforeAll anywhere in this example code so I would say there is one of two possible problems.
There is a beforeAll method with an issue somewhere not in this code sample.
The before hook shown here is returning a non-promise object.
In your code you are using a lambda function to do the work of before but if app.start() is returning an object which is not a promise then that would be your issue. Try refactoring it more like this:
before(() => {
app.start()
})
If your app.start() function is asynchronous you may need to pass the done handler into it:
before((done) => {
app.start(done)
})
Or possibly convert your app.start() function to return a promise which should resolve it. You may need to add async () => await app.start() but I don't think that would be necessary for a single expression like this.
You didn't use "done" as a callback in your it-function. You also don't have to use done in the describe callback. Also, since done() already makes your code asynchronous, you don't have to use the async keyword.
My solution:
describe ('Application launch', function() {
this.timeout(30000);
const app = new Application({
path: electronBinary,
args: [baseDir],
});
before(() => app.start());
after(() => app.stop());
it('shows an initial window', (done) => {
await app.client.waitUntilWindowLoaded();
const count = app.client.getwindowcount();
assert.equal(count,1);
done();
});
});
Hope it helps!
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 am writing a node application with mocha and chai. Some of the tests call an external API for integration tests, which might take up to 90sec to perform the action.
In order to cleanup properly, I defined an afterEach()-block, which will delete any generated remote resources, in case an expect fails and some resources weren't deleted.
The tests themselves have an increased timeout, while the rest of the tests should retain their default and small timeout:
it('should create remote resource', () => {...}).timeout(120000)
However, I can't do the same with afterEach().timeout(120000), because the function does not exist - nor can I use the function ()-notation due to the unknown resource names:
describe('Resources', function () {
beforeEach(() => {
this._resources = null
})
it('should create resources', async () => {
this._resources = await createResources()
expect(false).to.equal(true) // fail test, so...
await deleteResources() // will never be called
})
afterEach(async() => {
this._resources.map(entry => {
await // ... delete any created resources ...
})
}).timeout(120000)
})
Any hints? Mocha is version 4.0.1, chai is 4.1.2
The rules are same for all Mocha blocks.
timeout can be set for arrow functions in Mocha 1.x with:
afterEach((done) => {
// ...
done();
}).timeout(120000);
And for 2.x and higher it, beforeEach, etc. blocks are expected to be regular functions in order to reach spec context. If suite context (describe this) should be reached, it can be assigned to another variable:
describe('...', function () {
const suite = this;
before(function () {
// common suite timeout that doesn't really need to be placed inside before block
suite.timeout(60000);
});
...
afterEach(function (done) {
this.timeout(120000);
// ...
done();
});
});
Mocha contexts are expected to be used like that, since spec context is useful, and there are virtually no good reasons to access suite context inside specs.
And done parameter or promise return are necessary for asynchronous blocks.
If you need to use dynamic context you have to use normal function.
describe('Resources', function () {
// ...
afterEach(function (){
this.timeout(120000) // this should work
// ... delete any created resources ...
})
})
I'm trying to get the results from a mock backend in Angular 2 for unit testing. Currently, we are using fakeAsync with a timeout to simulate the passing of time.
current working unit test
it('timeout (fakeAsync/tick)', fakeAsync(() => {
counter.getTimeout();
tick(3000); //manually specify the waiting time
}));
But, this means that we are limited to a manually defined timeout. Not when the async task is completed. What I'm trying to do is getting tick() to wait until the task is completed before continuing with the test.
This does not seem to work as intended.
Reading up on the fakeAsync and tick the answer here explains that:
tick() simulates the asynchronous passage of time.
I set up a plnkr example simulating this scenario.
Here, we call the getTimeout() method which calls an internal async task that has a timeout. In the test, we try wrapping it and calling tick() after calling the getTimeout() method.
counter.ts
getTimeout() {
setTimeout(() => {
console.log('timeout')
},3000)
}
counter.specs.ts
it('timeout (fakeAsync/tick)', fakeAsync(() => {
counter.getTimeout();
tick();
}));
But, the unit test fails with the error "Error: 1 timer(s) still in the queue."
Does the issue here in the angular repo have anything to do with this?
Is it possible to use tick() this way to wait for a timeout function? Or is there another approach that I can use?
The purpose of fakeAsync is to control time within your spec. tick will not wait for any time as it is a synchronous function used to simulate the passage of time. If you want to wait until the asynchronous function is complete, you are going to need to use async and whenStable, however, in your example, the spec will take 3 seconds to pass so I wouldn't advise this.
The reason why the counter.spec.ts is failing is that you have only simulated the passage of 0 seconds (typically used to represent the next tick of the event loop). So when the spec completes, there are still mocked timers active and that fails the whole spec. It is actually working properly by informing you that a timeout has been mocked an is unhandled.
Basically, I think you are attempting to use fakeAsync and tick in ways for which they were not intended to be used. If you need to test a timeout the way that you have proposed, the simplest way would be to mock the setTimeout function yourself so that, regardless of the time used, you can just call the method.
EDITED
I ran into a related issue where I wanted to clear the timers, and since it was not the part under test, I didn't care how long it took. I tried:
tick(Infinity);
Which worked, but was super hacky. I ended up going with
discardPeriodicTasks();
And all of my timers were cleared.
Try to add one or a combination of the following function calls to the end of your test:
flush();
flushMicrotasks();
discardPeriodicTasks();
or try to "kill" the pending tasks like this:
Zone.current.get('FakeAsyncTestZoneSpec').pendingTimers = [];
Zone.current.get('FakeAsyncTestZoneSpec').pendingPeriodicTimers = [];
flush (with optional maxTurns parameter) also flushes macrotasks. (This function is not mentionned in the Angular testing tutorial.)
flushMicrotasks flushes the microtask queue.
discardPeriodicTasks cancels "periodic timer(s) still in the queue".
Clearing the pending (periodic) timers array in the current fake async zone is a way to avoid the error if nothing else helps.
Timers in the queue do not necessarily mean that there's a problem with your code. For example, components that observe the current time may introduce such timers. If you use such components from a foreign library, you might also consider to stub them instead of "chasing timers".
For further understanding you may look at the javascript code of the fakeAsync function in zone-testing.js.
At the end of each test add:
fixture.destroy();
flush();
Try this:
// I had to do this:
it('timeout (fakeAsync/tick)', (done) => {
fixture.whenStable().then(() => {
counter.getTimeout();
tick();
done();
});
});
Source
Async
test.service.ts
export class TestService {
getTimeout() {
setTimeout(() => { console.log("test") }, 3000);
}
}
test.service.spec.ts
import { TestBed, async } from '#angular/core/testing';
describe("TestService", () => {
let service: TestService;
beforeEach(() => {
TestBed.configureTestingModule({
providers: [TestService],
});
service = TestBed.get(TestService);
});
it("timeout test", async(() => {
service.getTimeout();
});
});
Fake Async
test.service.ts
export class TestService {
readonly WAIT_TIME = 3000;
getTimeout() {
setTimeout(() => { console.log("test") }, this.WAIT_TIME);
}
}
test.service.spec.ts
import { TestBed, fakeAsync } from '#angular/core/testing';
describe("TestService", () => {
let service: TestService;
beforeEach(() => {
TestBed.configureTestingModule({
providers: [TestService],
});
service = TestBed.get(TestService);
});
it("timeout test", fakeAsync(() => {
service.getTimeout();
tick(service.WAIT_TIME + 10);
});
});
I normally use the flushMicrotasks method in my unit tests for use with my services. I had read that tick() is very similar to flushMicrotasks but also calls the jasmine tick() method.
For me all above didnt helped, but a double call of tick(<async_time>) in my test code.
My explanation so far: for every async call you a need a single/own tick()-call.
I have a .pipe(debounceTime(500)) and a timer(500).subscribe(..) afterwards and this helped:
tick(500);
tick(500);