Jest 27: jest.setTimeout has no effect when used in async test

[AlCalzone]

💥 Regression Report

Last working version

Worked up to version: 26.6.3

Stopped working in version: 27.0.0

To Reproduce

Steps to reproduce the behavior:

1. Have an async test that takes longer than 5 seconds
2. Use jest.setTimeout(10000) to increase timeout
3. Run test, see this
   

Expected behavior

jest.setTimeout(...) to have an effect like it did in v26.

Link to repl or repo (highly encouraged)

https://github.com/AlCalzone/jest-settimeout-repro

1. clone the repo
2. yarn && yarn test

Run npx envinfo --preset jest

Paste the results here:

  System:
    OS: Windows 10 10.0.19041
    CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
  Binaries:
    Node: 12.22.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.14.13 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    jest: ^27.0.4 => 27.0.4

[Krillian111]

I had the same problem and was able to (temporarily) resolve it by moving the jest.setTimeout(...) to the top level scope, i.e. outside of the describe block. This is obviously not ideal as it applies to all tests within that file but might help some people until this is issue fixed.

In this related issue the author also mentioned that setting the timeout in the global jest config still works.

[psxpa3]

Hello @AlCalzone , can you tell me what is the ts-jest, @types/jest versions are you using with jest @26.6.3 for which test cases are working?

Hello @Krillian111 when we say setting the timeout in the global jest config, did you mean in the test file or in the beforeAll() of jest.config.json file?. Actually, I tried both for jest V27, but still getting the same error. Even increased the timeout value to 60000, but still no difference.

Your inputs are highly appreaciated, since have been dealing with the error on the 2nd day. Have already tried whatever found on the Google.

[AlCalzone]

ts-jest not used, I'm using babel-jest ^26.6.3
@types/jest: ^26.0.23

[imjordanxd]

experiencing the same problem. I was using setTimeout to flush promises/simulate a period of time passing (in legacy tests). I suspect this is related to the new "modern" implementation of timers and how the globals such as setTimeout are modified.

[seffs]

Using @babel/preset-env ^7.14.8 and jest ^27.0.5 I encountered the same behaviour. If the timer is meant to last per test, just add the timeout value as a parameter as showed in #5055 (comment)

It worked for me

[dannomayernotabot]

also encountered this issue, @seffs solution works like a charm. thank you!

[TrejGun]

"@types/jest": "27.0.1",
"jest": "27.2.0",
"ts-jest": "27.0.5",

solution with global timeout works for me as well

[DesignByOnyx]

This is still happening for me. Passing a 3rd argument to the it function works, but it destroys the readability of the test - it looks like some random number hanging out at the end of a test when I'd rather declare jest.setTimeout(...) at the top of a test. Not a deal breaker, but would definitely like to nudge this issue a little bit.

[CodexHere]

Hard to believe in 2022 this is STILL an issue, but here we are!

[DesignByOnyx]

It's even harder to believe that it's 2022 and people still troll around leaving useless condemning comments on free open source projects. There are numerous related issues and workarounds, thereby making this a very minor inconvenience. You're also welcome to fix it yourself and open a PR, or maybe even start a bounty to encourage someone else to fix it. Or nothing... you could try doing absolutely nothing... and that would be more helpful than your comment.

[dannomayernotabot]

Zing!

On Mon, Aug 1, 2022 at 2:11 PM Ryan Wheale ***@***.***> wrote: It's even harder to believe that it's 2022 and people still troll around leaving useless condemning comments on free open source projects. There are numerous related issues and workarounds, thereby making this a very minor inconvenience. You're also welcome to fix it yourself and open a PR, or maybe even start a bounty to encourage someone else to fix it. Or nothing... you could try doing absolutely nothing... and that would be more helpful than your comment. — Reply to this email directly, view it on GitHub <#11543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP65RMX5Q5HYQNZWVGCFZETVXA4RPANCNFSM46J6MZCA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Danno Mayer Cell: (206) 920-0056 ***@***.*** https://www.linkedin.com/in/dvmayer/

[slinkardbrandon]

For now a simple replacement that worked for me was using

it('should be a long running test', async () => {
  expect(true).toBe(true);

  // Setting the time here as a second parameter seems to work even with async.
}, 30_000)

[meowdao]

Let me tell you something about open source - most of the time it is half-assed. I do not say commercial software is good, but open sourse is half-assed ridiculously often. The reason for this is some "bright" guy from company with recognizable name, say F, has decided to make integration of technology X and Y. He created PoC and then just lost interest to the project because got what he was aming for. The the community saw that there is a nice new project with some potential and started to make contributions that were eventually merged to the project that made It looks like it is alive. Now we have zombi project and nobody tries to create a clone or replacement for years, because it is supported by the guy from F and thus by F itself. You know what I mean? Then there are different scenario like we all know eslint-plugin-node (that is kinda of good scenario) and jest/typescript/typeorm/react-router/react-big-calendar/etc... where we have such stupid issues lasting for years. Jest was developed as the replacement of everdiying mocha but apperently shares the same destiny. So stop bitching about bad community that is bugging you for years and fix that damn bug.

PS just want to say special "hello" to some of those guys who values their time and shits on the community @taion @pleerock

[piranna]

You have written such an awesome post. Have you though about writting a PR to fix this issue? I'm not sure if It would take you less time than the one you've employ on your rant, but definitely It would have cost you less characters and key strokes.

[arboledavargas]

It's even harder to believe that it's 2022 and people still troll around leaving useless condemning comments on free open source projects. There are numerous related issues and workarounds, thereby making this a very minor inconvenience. You're also welcome to fix it yourself and open a PR, or maybe even start a bounty to encourage someone else to fix it. Or nothing... you could try doing absolutely nothing... and that would be more helpful than your comment.

For the people that don't want or not have time to learn the internals of the library and don't want to fix themselves every little error they found the only thing they can do is live with the problem , you say is free but they have other forms of make money , there is a lot of companies making money using free software. we want better libraries or at least listen to the people. these people travel the world talking about their library full of bugs making money with a "mediocre" software.

[sempasha]

Documentation for this method states:

Set the default timeout interval (in milliseconds) for all tests and before/after hooks in the test file. This only affects the test file from which this function is called. The default timeout interval is 5 seconds if this method is not called.

My understanding of default timeout is that it is something that must be configured before running any tests. For that I assume this method as not suitable for application inside of a test body. In that case this method must throws an Error when called inside of a test body, no matter sync or async. And documentation must be clear about the idea of the method and about consequences of calling it inside a test body.

Maybe author(s) of method has different view and it is allowed to change default test timeout during test execution. In that case current behavior is incorrect. Effect after calling this method inside test body must be the same no matter what kind of test it is sync or async.

@aaronabramov could you please clarify the idea of this method?