Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Linux] "Async callback was not invoked within the 5000ms timeout specified by jest.setTimeout.", but a 30000ms timeout WAS defined. #6557

Closed
sgarcia-dev opened this issue Jun 26, 2018 · 7 comments

Comments

@sgarcia-dev
Copy link

sgarcia-dev commented Jun 26, 2018

🐛 Bug Report

I'm trying to run a selenium test using Jest, and despite trying to increase the async callback time limit via multiple ways, it's not detecting them when I run my tests on a Linux machine running a Jenkins Job, it uses Node v8.8.3 LTS via NVM (Works fine on MacOS using Node v10).

I originally thought it was an issue on my end, but since I've pretty much tried everything suggested on both the Jest docs, other Jest issues, and Stackoverflow questions, I'm now of the belief this might be a Jest bug which just isn't properly documented.

To Reproduce

Steps to reproduce the behavior (can only reproduce on Linux machine using Node v8.8.3 afaik):

const webdriverio = require('webdriverio');
const client = webdriverio.remote({
    desiredCapabilities: {
        browserName: 'chrome'
    } 
});

beforeEach(async () => {
    await client.init();
})

test('Google Search for WebdriverIO has correct title', async (done) => {
    jest.setTimeout(30000)
    // Saw this suggested somewhere, didn't work. Not here, nor in the global setup file.
    // if (jasmine) {
    //     jasmine.DEFAULT_TIMEOUT_INTERVAL = 30000;
    // }
    await client.url('https://www.google.com/ncr');
    await client.setValue('input[name=q]', 'WebdriverIO');
    await client.click('input[value="Google Search"]');
    const title = await client.getTitle();
    expect(title).toBe('WebdriverIO - Google Search');
    done();
}, 30000);

afterEach(async () => {
    await client.end();
});

Expected behavior

Tests to run consistently between both machines.

Link to repl or repo (highly encouraged)

This is the Github repo I'm using, the tests are run using npm run jest-test
https://github.com/sgarcia-dev/selenium-grid-test

Run npx envinfo --preset jest

Paste the results here:

11:06:39   System:
11:06:39     OS: Linux 4.14 Amazon Linux AMI 2018.03
11:06:39     CPU: x64 Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
11:06:39   Binaries:
11:06:39     Node: 8.11.3 - ~/.nvm/versions/node/v8.11.3/bin/node
11:06:39     npm: 6.1.0 - ~/workspace/mad-web-regression-chrome/node_modules/.bin/npm
11:06:39   npmPackages:
11:06:39     jest: ^23.2.0 => 23.2.0 
@joeferraro
Copy link

We're seeing similar behavior intermittently on Travis CI builds

@ftes
Copy link
Contributor

ftes commented Aug 9, 2018

This helped me: https://stackoverflow.com/a/49864436/5811158

// jest.config.js
module.exports = {
  setupTestFrameworkScriptFile: './jest.setup.js'
}

// jest.setup.js
jest.setTimeout(30000)

Specifically, this sets the timeout in the setupTestFrameworkScriptFile. As per the documentation, this differs from setupFiles b/c it is executed at a later point at which the test framework (jasmine) is already available.

I don't understand why calling jest.setTimeout within the test itself does not produce the same results (as you and I both expected).

@thymikee
Copy link
Collaborator

thymikee commented Aug 9, 2018

jest.setTimeout should be called before the test, because it must know the time limit prior to its execution. Want to update the docs to make it clear? :)

@ftes
Copy link
Contributor

ftes commented Aug 9, 2018

Sure, PR incoming.

@nazreen
Copy link

nazreen commented Oct 26, 2018

this issue should already be closed, no?

@thymikee
Copy link
Collaborator

Yup, thanks!

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants