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

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.

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

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.

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 https://github.com/facebook/jest/issues/11543#issuecomment-1201725810, 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/

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)

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 https://github.com/facebook/jest/issues/5055#issuecomment-558316914

It worked for me

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.

let me explain something to you expletive and maybe… just may be… you will understand. a day has 24 hours. 9 hrs goes to sleep, 9 hrs goes to work, 2 hrs goes to exercise prep and eat food – that is 20 hrs and is a pretty moderate disposition.

that leaves 4 hrs on weekdays and 13 hrs on weekends which is 76 hrs a week.

how many hours do you need to wrap your head around this issue… depends… but lets be generous and for someone who never looked at the jest codebase before it could easily take 40 hrs. (8 hrs week)

dont know what you expletive do for a living but i will speak for us full stack engineers who deal with gazillions of open source frameworks and having very moderately speaking 3 issues like this on a daily basis.

so if we were to use your genius approach to fix everything we come across we’d accumulate 3*40 = 120 hrs of work each week at that would leave us 44 hrs behind each week.

44 hrs behind each week. and that is living a very dedicated lifestyle of just coding which doesnt allow time for gf, any kind of fun, personal errands even dr. appts etc etc – forget travelling – that is the no-life lifestyle and even with that lifestyle you’d be left behind 44 hrs behind each week.

now, most time we dont even get to choose what frameworks we want to use so we’d be stuck with whatever expletive framework that expletive manager of ours picks.

SO lots of expletives

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

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.

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.